Using the STL will not serve any purpose as programming practice |
As stated above, I disagree.
As for the second point, let's consider the code:
1 2 3 4 5 6 7
|
int ArrayClass::find(int number)
{
for (int i = 0; i < theArraySize; i++)
if (theArray[i] == number)
return i;
return -1;
}
|
Observations:
- is int actually the same range as size_t? Even in the positive integers? (possible errors with theArraySize and i. Or can an array be any size in the range of int values?)
- i++ creates an unnecessary temorary object (could be avoided by ++i)
- return -1 requires pretty much care when using. Any sensible C++ (or even C) programmer will assume that find returns the "past-the-end" pointer if not succssful.
So, no, this code has no bugs until invoked with wrong parameters in which case it will be hard to debug. Furthermore it does not obey the canonical way of range handling, which *will* lead to errors in the client code.
Another point is that you *have to look at it*. You have to learn that it returns -1 when not successful - which is unproductive. Reuse standard code, and all are happy.
On a last remark, I don't want to talk any solution here "bad". What I basically tried to say is "prefer the usage of the stl instead of home-brew code" and I showed the way how to do it in the given case. My statement about the difficulty of re-use and ease of writing own (but untested) solutions is a general one, not directly inspired by any code posted in this thread (e.g., would you know exactly (and without looking something up) what the requirements for a parameter used in the place of std::greater are? I would not, but I would be abel to write the "count"-algorithm without going to my bookshelf and most likely be done before I could even reached the latter. Nonetheless I prefer reusing the stl because I have to manage and maintain my code).