For which one the space is allocated first when the derived class object is created?
whether base class constructor or derived class constructor?
First,
allocation, the reservation of memory which you’re asking about, is different from and precedes initialization (execution of a constructor that essentially sets suitable values in that memory), and
the formal (our Holy Standard) and the in-practice differ on whether memory for a most derived object needs to be contiguous, with the formal defining a “region of memory” as possibly non-contiguous, mostly in order to support multiple virtual inheritance.
That said, in practice a most derived object is a single, contiguous chunk of memory that includes space for all base class sub-objects and data member sub-objects, and this chunk is necessarily allocated all at once.
Initialization (calls of constructors) proceeds after the allocation. A new expression guarantees a deallocation if initialization fails by throwing an exception. However, this guarantee is voided if the allocation function that’s employed has extra custom arguments (a so called “placement new”) and no corresponding deallocation function is available, as was the case e.g. for debug builds in early versions of Microsoft’ MFC class framework (it was pretty ironic: a program where initialization failed would leak memory only in debug builds…).
The space for the derived object holds all of the derived members and all of the base members. There is only one allocation for the derived object, and the allocated memory holds all the pieces of the object.
As mentioned in the comment it is the Base class. Logically, since you can access the base public and protected members in the Derived class (including constructor) it will need to be allocated first. Try starting with the following code and play around.
#include <iostream>
class Base
{
public:
Base() {std::cout<<"Base CTOR" << std::endl;}
};
class Derived : public Base
{
public:
Derived():Base() {std::cout<<"Derived CTOR"<<std::endl;}
};
int main(int argc, char* argv[])
{
Derived d;
}
Related
There is already a question asking about the "real-world" behavior of deleteing a pointer to a base class that lacks a virtual destructor, but the question is restricted to a very limited case (the derived class has no members with non-trivial destructors), and the accepted answer just says there's no way to know without checking the behavior of every compiler.
....but that isn't actually very helpful; knowing that every compiler might behave differently doesn't tell us anything about the behavior of any particular compiler. So, what do Clang and G++ do in this case? I would assume they would simply call the base-class destructor, then deallocate the memory (for the entire derived class). Is this the case?
Or, if it's not possible to determine this for all versions of GCC and Clang, how about GCC 4.9 and 5.1, and Clang 3.5 through 3.7?
First, the standard disclaimer: this is undefined behavior, so even with one specific compiler, changing the compiler flags, the day of the week, or the way you look at the computer could change the behavior.
The following all assumes you have some sort of at least slightly non-trivial destruction happening in your destructors (e.g., the objects delete some memory, or contain object others that themselves delete some memory).
In the simple case (single inheritance) you typically get something roughly equivalent to static binding--that is, if you destroy a derived object via a pointer to a base object, only the base constructor is invoked so the object isn't destroyed properly.
If you use multiple inheritance, and you destroy an object of derived class via the "first" base class, it'll typically be about the same as if you used single inheritance--the base class destructor will be invoked, but the derived class destructor won't be.
If you have multiple inheritance and destroy a derived object via a pointer to the second (or subsequent) base class, your program will typically crash. With multiple inheritance, you have multiple base class objects at multiple offsets in the derived object.
In the typical case, the first base class will be at the beginning of the derived object, so using the address of derived as a pointer to the first base class object works about the same as in the single inheritance case--we get the equivalent of static binding/static dispatch.
If we try this with any of the other base classes, a pointer to the derived doesn't point to an object of that base class. The pointer needs to be adjusted to point to the second (or subsequent) base class before it can be used as a pointer to that type of object at all.
With a non-virtual destructor, what'll typically happen is that the code will basically take that address of that first base class object, do roughly the equivalent of a reinterpret_cast on it, and try to use that memory as if it were an object of the base class specified by the pointer (e.g., base2). For example, let's assume base2 has a pointer at offset 14, and base2's destructor attempts to delete a block of memory it points at. With a non-virtual destructor, it'll probably receive a pointer to the base1 subject--but it'll still look at offset 14 from there, and try to treat that as a pointer, and pass it to delete. It could be that base1 contains a pointer at that offset, and it's actually pointing at some dynamically allocated memory, in which case this might actually appear to succeed. Then again, it could also be that it's something entirely different, and the program dies with an error message about (for example) attempting to free an invalid pointer.
It's also possible that base1 is smaller that 14 bytes in size, so this ends up actually manipulating (say) offset 4 in base2.
Bottom line: for a case like this, things get really ugly in a hurry. The very best you can hope for is that the program dies quickly and loudly.
Just for kicks, quick demo code:
#include <iostream>
#include <string>
#include <vector>
class base{
char *data;
std::string s;
std::vector<int> v;
public:
base() { data = new char; v.push_back(1); s.push_back('a'); }
~base() { std::cout << "~base\n"; delete data; }
};
class base2 {
char *data2;
public:
base2() : data2(new char) {}
~base2() { std::cout << "~base2\n"; delete data2; }
};
class derived : public base, public base2 {
char *more_data;
public:
derived() : more_data(new char) {}
~derived() { std::cout << "~derived\n"; delete more_data; }
};
int main() {
base2 *b = new derived;
delete b;
}
g++/Linux: Segmentation fault
clang/Linux: Segmentation fault
VC++/Windows: Popup: "foo.exe has stopped working" "A problem caused the program to stop working correctly. Please close the program."
If we change the pointer to base instead of base2, we get ~base from all the compilers (and if we derive only from one base class, and use a pointer to that base class, we get the same: only that base class' destructor runs).
If you delete an object without a virtual destructor, the compiler will probably assume that the deleted address is the address of the most derived object.
Unless you use a primary base class to delete the object, this won't be the case, so the compiler will call operator delete with an incorrect address.
Of course the compiler will not call the destructor of the derived class, or operator delete of the derived class (if there is one).
We use a framework that relies on memcpy in certain functions. To my understanding I can give everything that is trivially copyable into these functions.
Now we want to use a simple class hierarchy. We are not sure whether we can have a class hierarchy that results in trivially copyable types because of the safe destruction. The example code looks like this.
class Timestamp; //...
class Header
{
public:
uint8_t Version() const;
const Timestamp& StartTime();
// ... more simple setters and getters with error checking
private:
uint8_t m_Version;
Timestamp m_StartTime;
};
class CanData : public Header
{
public:
uint8_t Channel();
// ... more setters and getters with error checking
private:
uint8_t m_Channel;
};
The base class is used in several similar subclasses. Here I omitted all constructors and destructors. Thus the classes are trivially copyable. I suppose though that the user can write a code that results in a memory leak like this:
void f()
{
Header* h = new CanData();
delete h;
}
Is it right that the class hierarchy without the virtual destructor is a problem even if all classes use the compiler's default destructor? Is it therefore right that I cannot have a safe class hierarchy that is trivially copyable?
This code
Header* h = new CanData();
delete h;
will trigger undefined behavior since §5.3.5/p3 states:
In the first alternative (delete object), if the static type of the object to be deleted is different from its
dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the
static type shall have a virtual destructor or the behavior is undefined
and regardless of not having dynamically allocated objects contained in your derived class (really bad if you have), you shouldn't do it. Having a class hierarchy without the base class virtual destructor is not a problem per se, it becomes a problem when you try to mix static and dynamic types with delete.
Doing memcpy on a derived class object smells of bad design to me, I would rather address the need for a "virtual constructor" (i.e. a virtual clone() function in your base class) to duplicate your derived objects.
You can have your class hierarchy that is trivially copyable if you make sure that your object, its subobjects and base classes are trivially copyable. If you want to prevent users referring to your derived objects via base classes you could, as Mark first suggested, render the inheritance protected
class Header
{
public:
};
class CanData : protected Header
{ ^^^^^^^^^
public:
};
int main() {
Header *pt = new CanData(); // <- not allowed
delete pt;
}
Notice that you won't be able to use base pointers at all to refer to derived objects due to §4.10/p3 - pointer conversions.
If you delete a pointer to a derived type held as its base type and you don't have a virtual destructor, the derived types destructor won't be called, whether it's implicitly generated or not. And whether its implicitly generated or not, you want it to be called. If the derived type's destructor wouldn't actually do anything anyway though, it might not leak anything or cause a problem. If the derived type holds something like a std::string, std::vector, or anything with a dynamic allocation, you want the dtors to be called. As a matter of good practice, you always want a virtual destructor for base classes whether or not the derived classes destructors need to be called (since a base class shouldn't know about what derives from it, it shouldn't make an assumption like this).
If you copy a type like so:
Base* b1 = new Derived;
Base b2 = *b1;
You will only invoke Bases copy ctor. The parts of the object which are actually from Derived will not be involved. b2 will not secretly be a Derived, it will just be a Base.
My first instinct is "don't do that - find another way, a different framework, or fix the framework". But just for fun let's assume that for certain your class copy doesn't depend in any way on the copy constructor of the class or any of its comprised parts being called.
Then since you're clearly inheriting to implement rather than to substitute the solution is easy: Use protected inheritance and your problem is solved, because they can no longer polymorphically access or delete your object, preventing the undefined behavior.
It's almost safe. In particular, there is no memory leak in
Header* h = new CanData();
delete h;
delete h calls the destructor of Header and then frees the memory pointed to by h. The amount of memory freed is the same as was initially allocated at that memory address, not the sizeof(Header). Since Header and CanData are trivial, their destructors do nothing.
However, you must provide a virtual destructor to base even if it does nothing (by requirement of the standard to avoid undefined behaviour). A common guideline is that a destructor for a base class must be either public and virtual or protected and nonvirtual
Of course, you must beware slicing as usual.
Thanks all for posting various suggestions. I try a summarizing answer with an additional proposal for the solution.
The prerequisite of my question was to reach a class hierarchy that is trivially copyable. See http://en.cppreference.com/w/cpp/concept/TriviallyCopyable and especially the requirement of a trivial destructor (http://en.cppreference.com/w/cpp/language/destructor#Trivial_destructor). The class cannot need a destructor implemented. This restricts the allowed data members, but is fine for me. The example shows only C-compatible types without dynamic memory allocation.
Some pointed out that the problem of my code is undefined behaviour, not necessarily a memory leak. Marco quoted the standard regarding this. Thanks, really helpful.
From my understanding of the answers, possible solutions are the following. Please correct me if I am wrong. The solution's point is that the implementation of the base class must avoid that its destructor can be called.
Solution 1: The proposed solutions use protected inheritance.
class CanData : protected Header
{
...
};
It works but avoids that people can access the public interface of Header. This was the original intention to have a base class. CanData needs to forward these functions to Header. In the consequece, I would reconsider to use composition instead of inheritance here. But the solution should work.
Solution 2: Header's destructor must be protected, not the base class as a whole.
class Header
{
public:
uint8_t Version() const;
const Timestamp& StartTime();
// ... more simple setters and getters with error checking
protected:
~Header() = default;
private:
uint8_t m_Version;
Timestamp m_StartTime;
};
Then no user can delete Header. This is fine for me, because Header has no purpose on its own. With public derivation, the public interface remains available to the user.
My understanding is that CanData needs not implement a destructor to call the base class's desctructor. All can use the default destructor. I am not completely sure about this though.
All in all, the answers to my questions in the end of the origial positing are:
Is it right that the class hierarchy without the virtual destructor is a problem even if all classes use the compiler's default destructor?
It is only a problem if your destructor is public. You must avoid that people can access you desctrutor, except for derived classes. And you must ensure that derived classes call (implicitely) the base class's destructor.
Is it therefore right that I cannot have a safe class hierarchy that is trivially copyable?
You can make your base class safe with protected inheritance or a protected desctructor. Then you can have a hierarchy of trivially copyable classes.
This question looks like the discussion in Virtual destructor: is it required when not dynamically allocated memory?
In an exam question, I have been asked:
- What should any base class that maintain pointers to dynamically allocated memory define?
I answered:
- A copy constructor and an assignment operator (to make sure NOT only pointers are copied... c.f. deep copy), and a destructor (to free allocated memory)
They said this is not correct because this base class should also define a virtual destructor instead of the plain destructor. Why?
If your class is intended to be used polymorphically, you'll likely have pointers to the base class that point to derived objects.
Deleting a derived object through a pointer to a base class with no virtual destructor causes undefined behavior. That's probably her reasoning.
5.3.5
3) In the first alternative (delete object ), if the static type of
the operand is different from its dynamic type, the static type shall
be a base class of the operand’s dynamic type and the static type
shall have a virtual destructor or the behavior is undefined. [...]
Your base class needs a virtual destructor if objects of derived classes are intended to be destroyed via a base-class pointer, like so
Base *pointer_to_base_class = new Derived;
delete pointer_to_base_class;
From your question, it is unclear whether this is the case. Perhaps another part of the question (or a previous question) made clear that such polymorphic destruction was intended. Or, perhaps you were taught during the class to always anticipate such use as a best practice.
They are not 100% correct. Virtual destructor is a must if
class hierarchy used with dynamic polymorphism AND
derived objects are destroyed via pointer to base.
Otherwise non-virtual destructor is OK. But in most cases even if only #1 is intended it's a good style to make destructor virtual regardless of #2.
Within the standard, most inheritance hierarchies have a virtual destructor at their base; however, sub_match is defined to public inherit from std::pair<BidirectionalIterator, BidirectionalIterator> and as such it could own dynamically allocated memory. In a related area, match_results is not required to but usually implemented to public inherit from std::vector<...> which definitely allocates memory.
Your examiner is not entirely incorrect, but the focus on dynamically allocated memory is a red herring and betrays a worrying ignorance of the standard; while in most implementations deleting a derived type by a pointer to base type without virtual destructor will result in destructing a sliced object, per the standard it is undefined behaviour.
Adding to the other answers: You could also envisage a situation where you do want a common base class, but you don't have any actual interface functions for it. But if you want RTTI and dynamic cast support, you need a virtual function in your class. A destructor can be just that function.
For example, imagine you're a recovering Java programmer and insist that everything is an Object. You might start your first C++ program like so:
class Object
{
public:
virtual ~Object() { }
};
Now Object can indeed serve as the ultimate polymorphic base class of each of your classes.
If you also think that Object should be abstract, you can even make the destructor pure-virtual:
class Object { public: virtual ~Object() = 0; }; Object::~Object() { }
To follow up with all good answers here this is good practice to declare a virtual destructor to ensure a proper clean-up when a class is supposed to be subclassed to form a hierarchy and you want to delete the derived object through a pointer to it. The C++ standard is clear on this:
when you want to delete a derived class object through a base class
pointer and the destructor of the base class is not virtual and the
result is undefined
By undefined behavior you could think of memory leaks for example if your derived class allocate some dynamic memories and you try to delete it later on through this base class. Your teacher was probably thinking of this scenario.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When to use virtual destructors?
If all the data members of a class (which has virtual function) and it's inherited class are of non pointer type (means it can not hold any dynamic memoroy), is it required to declare destructor as virtual?
Example
class base {
int x;
public:
virtual void fn(){}
};
class der: public base {
int y;
public:
void fn(){}
};
Here do we need a virtual destructor?
No, it's not always necessary. It's just a rule of thumb, and thus not always applicable.
The real rules says:
A destructor must be declared virtual when objects of derived classes are to be deleted through base class pointers.
Otherwise, deleting a derived class object through a base class pointer invokes undefined behavior. (The most likely outcome is that only the base class' destructor is called.)
Of course, that rule is quite a mouthful for newbies, hence the simpler rule of thumb, which is almost always right. It is very likely that you are managing dynamically created derived class objects through base class pointers in a polymorphic class hierarchy, and it is very unlikely that you do this for non-polymorphic class hierarchies.
A virtual destructor ensures that the inherited class destructor is called when you have a pointer to a base class.
In this particular case you don't need it, but a user could inherite from der another class (let it be foo) which uses -for example- dynamic memory allocation. In that case the destructor wouldn't be called unless he has a pointer of type foo.
So no, it's not "necessary" but if you already have at least a virtual function (hence you already have a VTABLE) there is no harm either. It's mandatory if you assume that those class are to be inherited by the user and are freed using a pointer to the base class.
No, it is not required and doing so at all times can even hurt performance.
You don't run into UB (undefined behavior) unless you delete a base class pointer actually storing a derived class object. So whether you need a virtual destructor depend on how your code actually creates and frees objects, not on the class alone.
Btw it doesn't matter whether a derived class requires any extra destruction compared to a base class - lacking a virtual destructor in case when delete is applied to a base class pointer storing a derived class object address is UB anyway.
Yes.
Anytime you create a class with a virtual function you need to declare the destructor also as virtual.
Consider this situation -
base *b = new der();
delete b;
Since you are operating on the base pointer, it doesn't know that it is actually an object of the child class and hence the destructor of the der is never called. Which might invaraibly lead memory leaks among other issues.
If I have:
struct Base
{
};
struct Derived : Base
{
};
And I create Derived in main:
Derived* d = new Derived;
where (on heap or on stack) is my base created? Am I reasoning correctly that a Base is a part of a Derived so it is created wherever Derived is created? Or does it work in some other way?
The base class contribution is generally part of the derived object (and so uses part of the object's memory along with the derived portion). Your example can make this irrelevant, however, because the base class portion takes up zero memory due to the C++ empty base class optimization.
Despite the fact that the derived struct is empty as well, the final object must be at least one byte in size, because all objects must take up space, to ensure that the addresses of two different objects will be different. See: Why is the size of an empty class not zero? for more info.
The Base is created in the same memory segment as the Derived. In your example, since you allocate Derived on the heap, the Base is also allocated on the heap. They form one contiguous object in memory.