Hi.
I'm studying polymorphism & inheritance and recently came across this clone() function that got me really confused.
what is this clone() function, and when do I need to worry about it?
thanks in advanced!
Hi.
I'm studying polymorphism & inheritance and recently came across this clone() function that got me really confused.
what is this clone() function, and when do I need to worry about it?
thanks in advanced!
When you need to copy an object of a derived class, but you are only working with (smart) pointers to the base class and shouldn't have to know that the object is of which derived class, then you'll have to worry about it
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
OK, great.
and copy constructors works as usual? I mean, derived class also inherits the Base's copy contructor, right?
Not quite: the derived class copy constructor would not accept a base class object as an argument to copy from.Originally Posted by Absurd
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
so what if I have a Base class with dynamic allocated memory?
do I need to explicitly call the Base's copy constructor from the derived class' copy constructor?
If you don't explicitly define the copy constructor of the derived class, then no, since the compiler generated one should do the right thing. Otherwise, you do (in the initialiser list), if that is the right thing to do (and it probably is).Originally Posted by Absurd
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
thanks for your help, laserlight.
but don't I have to explicitly define the copy constructor of the derived class?
otherwise I'll get stuck with a shallow copy of the Base's data members...
or maybe that's what you meant by "if that is the right thing to do"...?
sorry for the ignorance, this is all new to me.
No, you don't have to, unless the derived class itself would be doing some manual resource management, but in that case, I think it would be better to separate out their components into classes that manage their own resources.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
OK, consider the following code:
would you say that a CCtr is necessary here?Code:class A { protected: /* some pointers that points to * dynamic allocated memory here*/ public: A(){/*constructor*/} virtual ~A(){/*destructor*/} A(const A& a){/*some copy is going on right here*/} /* maybe some more methods here*/ }; class B: public A { /*some more functionality here, no CCtr here*/ }; void func(B obj) { /*some function*/ } int main() { B bObject; //sending bObject by value will trigger A's CCtr? func(bObject); }
what does "manual resource management" mean?
thanks again for the help.
appreciate it.
Not a good idea. Where feasible, you should be using the standard (or other) containers or smart pointers rather than such pointers with ownership. If you do need to have such a pointer for some reason, only have one per class. More than that and it usually becomes tricky to manage.Originally Posted by Absurd
Probably not.Originally Posted by Absurd
No, it will invoke B's copy constructor (which is more normally abbreviated as "copy ctor"). This copy constructor will then invoke the A sub-object's copy constructor.Originally Posted by Absurd
As a rule of thumb, if the resource is memory, it means that somewhere in your code, you are calling delete or delete[] to match some new or new[].Originally Posted by Absurd
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)