virtual functions

Started by
22 comments, last by Erzengeldeslichtes 18 years, 5 months ago
Quote:
"The virtual dispatch mechanism happens only through pointers." ...and references


Very true, I should have pointed that out.
Advertisement
That's okay, I did it for you ;)
Quote:Original post by Promit
The previous poster mentioned it, and I'd like to emphasize it.
You must avoid assigning a derived class to a base class by value.
When this happens, it's called slicing, because any data members of the derived class with be sliced off, and only the base class will be copied. Virtuality functions only through pointers and references. Be extremely careful when working with base class values; don't copy them as the base class, don't pass them by value to functions, don't insert them by value into containers, etc. Your omg vector is dangerous, and inserting a Test2 into it is a mistake. All of the information about Test2 is destroyed when you do that.

Oh, and if you want to attempt Zahlman's solution, be very careful. STL containers take some parameters by value instead of by const reference, so if your pointer wrapper's destructor deletes the pointer, you will always destroy your object when you attempt to add it to a container.


Yes; that's why I invoke clone() in the wrapper copy ctor, and expect the clone() to return a new copy-constructed instance of the object. The object's cctor semantics are supposed to be such that this is ok.

Zahlman while I admire your effort, it would be hard to catch me using a smart pointer implementation that's not maintained by something like the boost project - their effort is a result of several years of experts and end users providing feedback, bug reports, and corrections to the implementation so that it's as bug free and as usable as possible - many realize that it's a very difficult task to implement one that works correctly in the grand scheme of things, and I wouldn't recommend rolling your own for the same reason you shouldn't roll your own version of many other things found in the standard libraries or in libraries such as the boost libraries... Leave the library writing up to library writers (or work on your skills to become one yourself)...
Just don't anybody try to put a std::auto_ptr into an STL container. Wrong idea.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
I've yet to see if VC8 will allow it to compile - it's forbidden by the standard's rules, and hopefully most compilers will disallow it eventually.
It doesn't, which is rather disapointing. It would be simple to prevent the declaration of a container of auto pointers using a partial specialization that contained something as simple as a zero-length array data member. Naive example -
template <typename T> class vector<auto_ptr<T> > { int cant_make_container_of_auto_ptrs[0]; };
It seems like you want to have the child class perform the actions of the base class, plus other stuff? This works fine for me:
class Test2 : public Test1{    public:    void x()    {        Test1::x();        std::cout << "2";    }};
We''re sorry, but you don''t have the clearance to read this post. Please exit your browser at this time. (Code 23)
Quote:Original post by Deyja
It doesn't, which is rather disapointing.


Same with GCC. However, I assume VC8, just like GCC, will throw up errors if you try to preform any interesting operation on it (push_back, resize... anything potentially changing .size() to be something other than zero...)
Quote:Original post by erissian
It seems like you want to have the child class perform the actions of the base class, plus other stuff? This works fine for me:
class Test2 : public Test1{    public:    void x()    {        Test1::x();        std::cout << "2";    }};


Setting aside the slicing issues mentioned by others, that code wouldn't work as Lode appears to be desiring - you'd get 1 and 2 printed out on calling x(), not just 2. Plus it's a little odd to be calling a virtual function inside a function that is in theory overriding it. I'd argue that if you're needing code from a function that you're overriding, then it needs refactoring into a separate function that you're not overriding. It's also a lot clearer in maintenance.

Either way, he needs to be using something that is a pointer/reference to get virtual behaviour, whether a pointer directly in the vector or a suitable object that wraps a pointer that can be used in a vector (not auto_ptr in case anyone's missed the numerous references :)

This topic is closed to new replies.

Advertisement