What then, is the best practice in overloading operators on members of the stl vector class?
In particular, which of these three choices do you think is best?
i) to use operator overload to implement the operations I need to do on vectors but not inherit the class.
ii) to inherit the stl vector class and overload operators and
iii) to create my own class and implement all the operators I would need.
There is one reason and one reason only: Because the standard says so!
However this reason is very rarely satisfying, so I can provide some key points:
(1) The standard is very abstract about the implementation of the STL. There is nothing in the standard which prohibits STL implementors from using methods that completely break inheritance. However unless you take some very weird implementation there is not much which actually breaks inheritance. Not much however is not nothing. If you know which implementation you are using, it is actually quite safe to inherit from stl-classes (you just have to know what you are doing, and best add warnings for others, so they do not just copy your ideas).
(2) Almost all (maybe even all, not quite sure), STL-Containers have non-virtual destructors. This is the one feature which breaks inheritance. If you inherit in any implementation, make sure, to add absolutely no additional state to the class. If this is not possible, do not inherit.
(3) STL-Containers and algorithms are kept separate for a reason. The reason is modularity. If you have to add each algorithm to each container, this quickly becomes an NxM problem. In the STL algorithms are provided separately of the containers, reducing complexity to N+M. This works by having the algorithms run on iterators. In some cases though optimized versions are provided as methods (e.g. std::lower_bound versus std::set::lower_bound). The rule for C++ is often: When in doubt, do as the STL (or the other parts of the standard). If you can the best way is to also separate the algorithm from the container.
(4) The STL-Implementation is free to add any number of additional optional template parameters to the containers. This means although you could use templated classes to inherit from the container, this will only work for the implementation you are using with the same number of parameters. If the number of parameters does not match, you might loose functionality (Note: this may have changed with C++11 and variadic templates).
(5) Unlike in many other languages in C++ the best way to add functionality is to add a free standing method implementing that functionality. This works especially well, if no part of the internal state or no virtual methods are used.
(6) Usually it is possible to add any functionality and change functionality by just using encapsulations. It is not even necessary to provide your own iterator type, because you can safely export the one provided by the contained class. This way you can also limit the interface to the contained container making usage safer. If you really need the full interface to the container, this however ends in a lot of typing of forwarding methods, so this is a place where correct inheritance comes in handy.
So to answer the other part of the question on how to solve this best, here is my list:
1. Try to implement a generic method using iterators
2. Implement a free standing method for that type of container.
3. Build a class using the container which exports the correct functionality by using forwarding methods (also note, if the methods are done as in class methods they will be removed by inlining).
4. Inherit from the class and make sure language purist never see your code.
I cannot comment on the idea of using operator overloading, since this is often very dependen on the use case. In some cases it might be good to add additional overloaded operators, but then the semantics and usage should be very clear.
There is one reason and one reason only: Because the standard says so!
However this reason is very rarely satisfying, so I can provide some key points:
(1) The standard is very abstract about the implementation of the STL. There is nothing in the standard which prohibits STL implementors from using methods that completely break inheritance. However unless you take some very weird implementation there is not much which actually breaks inheritance. Not much however is not nothing. If you know which implementation you are using, it is actually quite safe to inherit from stl-classes (you just have to know what you are doing, and best add warnings for others, so they do not just copy your ideas).
(2) Almost all (maybe even all, not quite sure), STL-Containers have non-virtual destructors. This is the one feature which breaks inheritance. If you inherit in any implementation, make sure, to add absolutely no additional state to the class. If this is not possible, do not inherit.
(3) STL-Containers and algorithms are kept separate for a reason. The reason is modularity. If you have to add each algorithm to each container, this quickly becomes an NxM problem. In the STL algorithms are provided separately of the containers, reducing complexity to N+M. This works by having the algorithms run on iterators. In some cases though optimized versions are provided as methods (e.g. std::lower_bound versus std::set::lower_bound). The rule for C++ is often: When in doubt, do as the STL (or the other parts of the standard). If you can the best way is to also separate the algorithm from the container.
(4) The STL-Implementation is free to add any number of additional optional template parameters to the containers. This means although you could use templated classes to inherit from the container, this will only work for the implementation you are using with the same number of parameters. If the number of parameters does not match, you might loose functionality (Note: this may have changed with C++11 and variadic templates).
(5) Unlike in many other languages in C++ the best way to add functionality is to add a free standing method implementing that functionality. This works especially well, if no part of the internal state or no virtual methods are used.
(6) Usually it is possible to add any functionality and change functionality by just using encapsulations. It is not even necessary to provide your own iterator type, because you can safely export the one provided by the contained class. This way you can also limit the interface to the contained container making usage safer. If you really need the full interface to the container, this however ends in a lot of typing of forwarding methods, so this is a place where correct inheritance comes in handy.
So to answer the other part of the question on how to solve this best, here is my list:
1. Try to implement a generic method using iterators
2. Implement a free standing method for that type of container.
3. Build a class using the container which exports the correct functionality by using forwarding methods (also note, if the methods are done as in class methods they will be removed by inlining).
4. Inherit from the class and make sure language purist never see your code.
I cannot comment on the idea of using operator overloading, since this is often very dependen on the use case. In some cases it might be good to add additional overloaded operators, but then the semantics and usage should be very clear.
(ii) choice is the best. That is, inherit the stl vector and use your own operators.
Thanks for your answers.
Dear Mittal, I have a question on Method of lines, which I will post now. Kindly check my wall after some time. Thanks.
What would be the reason you would like to inherit the stl vector class?
Because I need to do all the algebra that are usually done with vectors.
In computer science a vector is a resizable array. There is no direct relation to the mathematical concept of vectors. If you know the size of your (mathematical) vectors, i.e. their dimension, in advance then using stl vectors is not a good choice (since you do not need the 'resizable' part). Implementing your own class based on a fixed size array (maybe with a templated size) would be a better idea.
A much better idea would be to use an existing library for linear algebra, e.g. Armadillo or EigenLib.
@Simon: In C++11 there is std::array for arrays with a size known at compile time. These can easily be used to build mathematical vectors. Indeed you are right, std::vectors are not the best choice for mathematical vectors.
If the size is not known in advance and can be set during execution, building a class using std::vector is probably best. In this class one can easily just export those portions of the std::vector that are needed, and remove all parts that have to do with resizing. As std::vectors may reserve more memory than is needed in case of resize operation, it is best to reserve all memory immediately when the std::vector is constructed and leave it that way. To make sure it would also be possible to call std::vector::shrink_to_fit at some strategic places, e.g. construction.
In most cases it is probably best, to use an existing linear algebra package. If needed with a thin wrapper for C++, since most packages will be in C not in C++, I fully agree with that.
Chinedu >> You don't need to derive your class from vector for doing what you plan, you just want to develop your own class and implement the operators you need.
If you want to make your class flexible (ie allowing to change/resize etc. the objects at runtime, using a user interface for example or starting the program with a size parameter), you should use std::vector, not std::array. If you need a fixed size and want to recompile the program every time the size changes, use std::array.
It is best if you implement your class in C++11, you will see how easy it is compared to older C++ versions.
No reason at all, as long you know what you're doing. Stroustrup himself says he often does it in "A tour of C++", section 9.2.2. on "Range checking". He inherits from std::vector in order to make operator[] range-checking by default.
(As others have pointed out, lack of virtual destructors will make it impossible to delete a pointer to your inherited vector "as if" it were a std::vector.).
One problem I have with C++ in general is the name spaces qualification causes variable names to be just plain confusing. Information overload isn't needed or helpful when you're trying to understand even your own algorithm. Being required (as a matter of some lame standard no less) to mentally parse long variable and type names significantly reduces the readability of code. By making an STL template a base class ALL the members of the base class become simply usable within the member functions. Like instead of "std::vector::iterator x;" in an incidental for loop you have "iterator x." This is clean, immediate and completely unambiguous no matter what the standard says. Outside the class one may use UserVectorThing::iterator which is also clean and significantly clearer to read. I almost always question standards in programming since they attempt to solve all problems with the same approach. The end result is lowest common denominator coding.
I don't have the expertise to comment on the preceding replies, but I'll add that while g++ appears to allow access to contents of a via a pointer to the first element, using plain C if you like, Intel C++ may forbid it in some contexts.
Much depend on the programmers work environment. What I suggest for small analytical research problems is that data hiding is counter productive. Lets say we want a vector of objects, classes or structs called "Particle." I would write,
class ParticleList : public vector {};
On really contrary days I might abbreviate this to,
struct ParticleList : vector{};
which in C++ is exactly the same using a class except all things are by default public. The advantage of using vector as a base class is that the API of the class is already made and everyone knows what it is at a glance. If one wishes to add, access, or delete a Particle use the members of the base class,
ParticleList parts;
parts.bush_back(Particle(1));
...
double energy = 0;
for (ParticleList::iterator p = parts.begin(); p != parts.end(); p++)
energy += p->mass() * pow(p->velocity(),2)/2;
and so on. All this API is built, known and ready to go. If at anytime in the future one needed to change the API just overload the base class ones and move on.
Strictly speaking as long as the inheritance is not explicitly disabled, by declaring private the constructors, there is no reason at all not to inherit from std::vector. However, you might consider aggregation instead of inheritance
@Bogdan: I think there is a problem with inheriting from std::vector. This type is part of the STL and thus has a prescribed interface. But, the actual implementation might differ for different systems and compilers. Hence, inheriting from std::vector and using implementation specific things to add your own methods/operators to the class makes things non-portable. This is different for other libraries because they usually have the same (or at least compatible) implementation for all platforms.
If it is just for simple use like Paul described, I think using inheritance is fine, though. But then you could also use
typedef std::vector ParticleList;
Paul >> "Like instead of "std::vector::iterator x;" in an incidental for loop you have "iterator x." This is clean, immediate and completely unambiguous no matter what the standard says."
Use C++11 and these sort of problems are gone. Code is also much cleaner and easier to understand. For example, your for loop
for (ParticleList::iterator p = parts.begin(); p != parts.end(); p++)
would be written in C++11 as
for(auto p : parts)
@Simon Implementation-specific things of std::vector are (hopefully) declared private, so you can't use them even with public inheritance.
@Paul:
I agree that types like "std::vector::iterator x;" are often very hard to read and can make the code a total mess. However classical C++ already offers a good solution for this, namely typedefs. Hence I have gotten into the habbit of doing like the STL does whenever I implement anything that looks remotely like a datastructure:
class datastructure { // based on std::vector
public:
typedef some_type value_type;
typedef std::vector container_type;
typedef container_type::iterator iterator;
...
This looks like a lot of typing at the beginning, but once one has formed the habbit it is actually pretty fast. It also has the nice effect of documenting the code structure and making it simple if I want to change the internal structure. All I have to change is the container_type.
This also gives the advantage of being able to use datastructure::iterator on the outside (and just iterator on the inside) without having to care about the real implementation.
Also C++11 solves a lot of problems with using auto. I have to admit I was very reluctant to use auto at the beginning, but now I declare most variable as auto. I was very impressed, how much more readable my code has become.
for( std::vector::const_iterator iter = v.begin();
has just become
for( auto iter = v.cbegin(); ...
other places have shrunk in similar ways.
Range based for loops can also improve readability in many places, but some compiler still do not implement them.
It seems that you want to have a vector type class with additional operators and not to build a classical "isa" relationship with vector.
Therefore as others have already said you should either use private inheritance or "composition" (has-a) to design the "is-implemented-as" vector. Composition (with a private member of type vector) is preferred (*) although it means that you have to replicate the vector interface and implement most of the methods so that they just invoke the original (vector's) ones.
(*) As Scot Meyers in Effective C++ says "use composition whenever you can, and use private inheritance whenever you must." (http://nova.polymtl.ca/~simark/Effective/Effective%20C++,%203rd%20Edition.download/0321334876/ch06lev1sec7.html)
Addition to Dale Smith,
STL stuff has no virtual member. So virtual table is not constructed so the polymorphism doesn't work. This means you cannot access to your class via std::vector pointer. The STL library doesn't be designed to be inherited, I guess.
I would recommend III).
@Hiroshi
As long as you do not add any member variables to your inherited class or overwrite existing methods, a missing virtual table is not a problem. No slicing will occur and the expected behavior is correct. In this case the class can be handed in wherever a pointer to an std::vector is needed. Whenever a function needs to access the additional methods/operators of the inherited class it just has to require an object of that class instead of std::vector.
To sum it up: Technically, it would work to inherit from std::vector and overload the operators. But, the real problem is that in the future someone (maybe a future you) will get the idea to extend the existing class. Everything about not adding any member variables to the class, etc. will be forgotten by then. In the end, some strange things will happen in your program (probably due to slicing) and nobody can easily find the bug. In order to save yourself some trouble in the future: Don't use inheritance to solve your problem!
Currently am using inheritance and it's working fine but your comments have really made things clear. Thanks all.
- Badges
- Science topic