Re: override vector::insert
Quote:
Originally Posted by paradoxresolved
I'm wrapping a class around vector such that, when this class is a member of a parent class, it automatically stores a pointer to the parent in the child object that is "pushed back" in the vector.
So it sounds like you are just saving typing, and there is no IS-A relationship as to why you publically derived from vector.
Quote:
Rats. I'm going to have to recreate the interface for .at(..), .push_back(..), .pop_back(), .size(), as well as .insert(..), and perhaps a few others that I'm not readily thinking of. . .
This is an indication that the interface wasn't fully thought through. I would expect, as a user of this tree class, functions such as AddNode(), RemoveNode(), GetNodeCount(), etc. and these functions would in turn call the internal vector's push_back(), pop_back(), size() etc. functions. The vector is hidden from the user, and the underlying data structure used to maintain the tree is not exposed. If in the future the vector needs to be changed to another data structure that has no "push_back" method, for example, then the clients using the tree class need not have to change their code. With your design, any client using the tree now needs to changed if in the future a "better" underlying structure is used.
Quote:
I have to go through all my code and set the parent at each and every instance of "push_back." It's highly time-consuming, messy, and error-prone.
I don't quite understand what you're saying. Maybe show a real life code example of what you are doing and where it is messy and time consuming.
Regards,
Paul McKenzie
Re: override vector::insert
Laserlight: Thank you, that was the case. I finally figured it out after two hours of head-to-wall trauma, copious cursing, and plenty of rum-n-coke.
Paul: I don't intend for anyone to ever use this code but me. When it is all finished, it will be wrapped up by an external interface.
Saving typing is one way to help make code less error prone. Why else would you tuck reduntant code into a function? Instead of setting a pointer to the parent at each time you push_back or insert something into a vector, the idea was to create a wrapper class that does it automatically, whenever something is push_back into its internally stored vector. I never have to worry about whether or not I remember to set the pointer. Now, it's impossible not to. If the object being stored is not of the appropriate type, it won't even store the object. I wanted the interface to the wrapper class to be similar enough to the way vectors work because I'm familiar with that interface. Actually, for my purposes, there are very few vector functions that I use on a typical basis, and since I no one else will be using these classes, I only needed to define a handful for the wrapper class interface.
That, and I never liked the way erase worked. Why don't they have vector<T>::erase(uint index)???? It seems more straightforward to me.
Re: override vector::insert
Quote:
That, and I never liked the way erase worked. Why don't they have vector<T>::erase(uint index)???? It seems more straightforward to me.
Just a guess : Probably to keep it consistent with other containers,
and, given the index, it is easy to come up with the iterator:
Code:
v.erase( v.begin()+index );
Quote:
Actually, for my purposes, there are very few vector functions that I use on a typical basis, and since I no one else will be using these classes, I only needed to define a handful for the wrapper class interface.
More and more it seems like containment (or private inheritance)
is the way to go.
std::stack (and the others like it), internally use a vector or list,
but only have a few vector/list member functions that they actually
allow client code to use.
Re: override vector::insert
Quote:
Originally Posted by paradoxresolved
Paul: I don't intend for anyone to ever use this code but me.
However, when we're asked a question that goes against all common C++ knowledge, be prepared to get more questions asked of why you're doing things this way.
Quote:
Saving typing is one way to help make code less error prone.
If you get a C++ interview question as to why public derivation is done, please don't say "to save typing". Public derivation is done to model the is-a relationship between a parent and base object. Yes, the by-product of public inheritance is that you do not need to implement code in the base class, but in no means is saving keystrokes the main reason for deciding to derive publicly from a class.
Quote:
Why else would you tuck reduntant code into a function?
Deciding whether to derive from a class is not the same principle as coming up with a generic function. If it were, 'C' programmers and other non-OO people would have no trouble with OO programs, as all a class would be is syntactic sugar for procedural calls (which of course, it isn't).
Quote:
I wanted the interface to the wrapper class to be similar enough to the way vectors work because I'm familiar with that interface.
So exactly what was wrong with Gniewerth's code? It is a "vector" class, in that it contains a vector and has routines that call the internal vector's functions.
Quote:
That, and I never liked the way erase worked. Why don't they have vector<T>::erase(uint index)???? It seems more straightforward to me.
Because STL uses the iterator concept for most of their functions and algorithms. If you need to erase an element after a find() is done, the iterator from find() can be used directly.
Regards,
Paul McKenzie
Re: override vector::insert
Actually, I did switch to his suggestion after his post. I was no longer deriving from vector, but was tucking it away as a member instead. That's what I meant before. Sorry. There must have been a miscommunication. I was just trying to carry over the functions from vector that I use the most into the interface of the enclosing class, but was having trouble getting them to work. I got it fixed last night. All is well.
Interviewing? Nah. This is my hobby. If it were my job, I would have to work on other people's projects, and it wouldn't be fun anymore. :)
Thanks for everyone's help!
