C++: destructor and delete

[Kevin Goodsell]

If you perform a delete on a object, which then calls it's destructor
method, and this method is simply empty. How is the original object actually
being deleted?

1) Even empty destructors do work. That work basically consists of
prepare the object to be deallocated.

2) The original object is (obviously) "actually being deleted" by the
runtime system. How that is accomplished is none of your business
(unless you happen to be using your own delete operator).

I can only assume the delete operator calls the destructor
method and then deletes

Replace "deletes" with "deallocates".

the original object

There is no object at this point, only raw memory. See footnote [1].

(outside of the destructor),
which you don't explicitly do yourself.

[1] The lifetime of an object goes like this: 1) Raw memory is
allocated. 2) A constructor is used to transform that raw memory into an
object. 3) The object is used (or not). 4) The destructor is used to
transform the object back into raw memory. 5) The raw memory is deallocated.

In the case of dynamically created objects, the 'new' operator does
steps 1 and 2. The 'delete' operator does steps 4 and 5.

-Kevin

 

[Kevin Goodsell]

The delete operator is only performed on pointers, so it calls the
destructor method of the object it's pointing to. In your case, the
destructor of X is called when the procedure returns.

You are simply, but thoroughly, wrong. Revisit your C++ book. You
obviously missed some very important points.

Dynamically created objects (that is, objects created via the 'new'
operator) don't have "scope" in the sense that, e.g., automatic
variables (those declared 'auto'[1], implicitly or explicitly - in other
words, local variables) do. Automatic variables go out of scope when
program execution leaves the scope they are declared in (usually
indicated by a '}'). This is not the case for dynamic objects. They
continue to exist until *YOU* apply the 'delete' operator to them. This
will NOT happen implicitly under any circumstances. It matters not at
all whether the function returns. (And they are called "functions" in
C++, not "procedures" or "methods". It helps if you use the right terms.)

[1] The 'auto' keyword is almost never used, but it is implicit for
local, non-static variables.

An object will always have a constructor and a If either is not
defined, they will be created for you implicitly. Since pointers are objects
too, they will have a constructor and destructor.

That's wrong. POD types don't have constructors and destructors. If they
did, they wouldn't do anything.

I do get statement 1 of my original post, but I did not get statement 1.

You get it but you don't? Statement 1 of your original post was
completely wrong. If you don't get it, that could be why.

Does not mean I have no authority to speak on the matter regarding statement
1? I don't think so.

Considering statement 1 is tripe, I don't see how it matters who has
authority to speak on it.

-Kevin

 

[John Harrison]

If you perform a delete on a object, which then calls it's destructor
method, and this method is simply empty. How is the original object actually
being deleted? I can only assume the delete operator calls the destructor
method and then deletes the original object (outside of the destructor),
which you don't explicitly do yourself.

sasas

delete frees memory, its calls the destructor before it frees the memory. If
the destructor is empty then all delete does is free memory.

john

 

[Karl Heinz Buchegger]

The delete operator is only performed on pointers, so it calls the
destructor method of the object it's pointing to. In your case, the
destructor of X is called when the procedure returns.

No. No destructor is called.
For the simple fact that there is no 'delete' in the above code.
When a pointer goes out of scope, nothing special happens, no
destructor is called, nothing gets freed. With respect to this,
a pointer is like an int. The variable vanishes into empty space,
but nothing special happens.

An object will always have a constructor and a destructor.

Yep.
But a pointer, like any other builtin type (int, long, char, double, pointers,...)
are *NOT* objects. Even if they were, there destructors would do: nothing.

If either is not
defined, they will be created for you implicitly. Since pointers are objects
too,

They are not.

they will have a constructor and destructor.

They don't have.

I do get statement 1 of my original post, but I did not get statement 1.
Does not mean I have no authority to speak on the matter regarding statement
1? I don't think so.

But your statement 1 is completely wrong.
Plain and simple: wrong. C++ does not work that way.

 

[Newsnet Customer]

No it isn't. I've said this twice now, three others have said it also.

How can I put it simply. You are wrong.

If you don't believe me why don't you try it. Put a cout << statement in the
destructor and see if the above code calls the destructor.

Tried it, and you are right.

Either:

1) dynamically created objects do not call their destructors when they go
out of scope - only for objects on the stack. OR
2) default destructor of pointers to dynamically created objects are called
when they go out of scope.

So is it 1 or 2? who knows.

OK, you can put it like that. But a pointer has a destructor WHICH DOES
NOTHING. It does not call delete.


I think you misunderstand statement one of your original post (you still
haven't said what the source of it is).

Basically your attitude is that you don't understand how destroy/delete
works, but when everyone tries to explain you refuse to accept it.

john

I don't just accept everything people tell me; Do you? of course not. I just
wasn't convinced by your argument and others. Anyway, I was partly wrong and
I will admit it. But I find your over-eagerness to judge people by calling
people "cocky" and referring to peoples attiitudes is not proper behaviour
in a public newsgroup.


asasas

 

[Nils Petter Vaskinn]

Either:

1) dynamically created objects do not call their destructors when they go
out of scope - only for objects on the stack. OR
2) default destructor of pointers to dynamically created objects are called
when they go out of scope.

So is it 1 or 2? who knows.

Neither. Dynamically created objects have no scope, so they cannot go out
of it. You usually have an automaticaly created variable that is a pointer
to your dynamically created object, and when that goes out of scope the
dynamic object still exists, you just have no way to get at it.


f()
{
A *p1;
{ // start of scope
A *p2; // automatic pointer variable
p2 = new A; // p1 now points to dynamically created object
p1 = p2; // p2 now points to the same dynamically created object
} // end of scope
/* p2 no longer exists but the object it pointed to still does even
though we have left the scope where it was created, calling
p2->do_something() would cause compilation to fail */

/* thankfully we can still access the object since we have another
pointer to it */
p1->do_something(); // prove it
delete p1; /* call destructor of the dynamically created object, then
free its memory */

/* p1 still exists and points to the memory where the object used to be
calling p1->do_something() now would be an error, but woul compile */
}


regards
NPV

 

[Peter van Merkerk]

Either:

1) dynamically created objects do not call their destructors when they go
out of scope - only for objects on the stack.

Dynamically created objects (meaning objects created with 'new') don't
go out of scope, period. Anything created with 'new', must be destroyed
with 'delete'.

2) default destructor of pointers to dynamically created objects are called
when they go out of scope.

One way to look at it is that pointers have a "do nothing" destructor.
Note a class can only have one destructor, hence the word 'default' has
no meaning in this context.

So is it 1 or 2? who knows.

Maybe some code will carify things:
void example1()
{
std::string s;
...
}

When example1() returns, the 's' instance of the std::string class goes
out of scope, and its destructor will be called.

void example2()
{
std::string* p = new std::string();
...
}

When example2() returns, the pointer 'p' goes out of scope. That means
that the pointer itself will be destroyed, but not the object it is
pointing to. The instance of std::string created with the new operator
will continue to exist even after p has been destroyed, hence its
destructor won't be called. If no other pointers to that std::string
object exist, it is no longer accessible by the program even though it
still exist. This also means that the object can't be deleted; this is a
classic example of a memory leak.

An alternative for raw pointers with their "do nothing" destructor, are
"smart pointer" classes (for example std::auto_ptr<T>), which have a
destructor that actually does something. The destructor of smart pointer
classes may actually delete the object they are pointing to when certain
conditions are met.

I don't just accept everything people tell me; Do you? of course not.

That is an healty attitude

I just wasn't convinced by your argument and others.

There is a difference between saying that you are not convinced and
saying someone is incorrect.

Anyway, I was partly wrong and
I will admit it. But I find your over-eagerness to judge people by calling
people "cocky" and referring to peoples attiitudes is not proper behaviour
in a public newsgroup.

Sometimes things sound more harsh on the other end of wire than
intended.

 

[jeffc]

Hi,

Statement 1: "A dynamically created local object will call it's destructor
method when it goes out of scope when a procedure returms"

Agree.


Statement 2: "A dynamically created object will call it's destructor when it
is made a target of a delete".

Does not make sense to me. Would not this result in an endless loop? (ie.
delete calls destructor and within destructor it calls delete, which in turn
calls the destructor again and so on....)

No, the destructor does not call delete. The delete causes the destructor to
be called, that's it. Also, your first statement is wrong. Dynamically
created objects do not get deleted, and do not have their destructor called,
merely because it goes out of scope. If that happens, it's a programmer
error.

 

[jeffc]

and whats USUALLY in the destructor method? a delete statement also,and
hence the loop.

Where did you get that idea?

 

[jeffc]

If you perform a delete on a object, which then calls it's destructor
method, and this method is simply empty. How is the original object actually
being deleted? I can only assume the delete operator calls the destructor
method and then deletes the original object (outside of the destructor),
which you don't explicitly do yourself.

No, delete does the delete. This is essentially the same as a free. It
tells the system to deallocate the memory. The destructor is not
necessarily even needed. It might be completely empty, and do nothing at
all.

 

[Kevin Goodsell]

I don't just accept everything people tell me; Do you? of course not. I just
wasn't convinced by your argument and others.

So you're just here to waste our time by arguing with people who clearly
know far more about the language than you do?

This is not a philosophical debate. There's no room for argument. There
is One Right Answer, which you were given *several* times, and ignored.
You are seeming more trollish with every post.

-Kevin

 

[Andrey Tarasevich]

...
Statement 1: "A dynamically created local object will call it's destructor
method when it goes out of scope when a procedure returms"

Agree.

The question makes no sense. Local objects, by definition, cannot be
dynamically created in C++. Local object can be either automatic or
static. Actually, the standard is rather ambiguous on whether locally
defined static objects can be referred to as "local", but in no case a
dynamically created object can be referred to as "local".

Statement 2: "A dynamically created object will call it's destructor when it
is made a target of a delete".

This question also makes no sense. Nowhere in C++ specification it says
that the object is responsible for calling its own destructor. The
destructor is called when the object is destroyed. Who performs the call
- no one knows.

OK, let's assume that the object being destroyed calls its own destructor.

Does not make sense to me. Would not this result in an endless loop? (ie.
delete calls destructor and within destructor it calls delete, which in turn
calls the destructor again and so on....)

No there's no endless loop here. Object's destructor doesn't call
'delete'. What makes you think it does?

 

[llewelly]

The delete operator is only performed on pointers, so it calls the
destructor method of the object it's pointing to. In your case, the
destructor of X is called when the procedure returns.



An object will always have a constructor and a destructor.

Not if the author of the class declares one and does not define it.

If either is not defined,

No. If either is not *declared* ...

they will be created for you
implicitly.

This class has no destructor.

struct has_no_destructor
{
private:
~has_no_destructor();
};

The same can be done with constructors and copy-assignment operators.

Since pointers are objects too, they will have a constructor and
destructor.

built-in types have 'trivial destructors'. (That's what the standard
calls them.) Note to other posters - nothing in the standard requires
they 'don't do anything' - it would be permissible for int's
destructor to set the bytes it occupied to '0xDEADBEEF' or
'0xCDCDCDCD' - and for a debugging implementation of C++, that
would even be desirable. The standard does define 'trivial
destructors' in such a way as to *allow* a trivial destructor to
do nothing, but there's no requirement.

 

[Andrey Tarasevich]

If you perform a delete on a object, which then calls it's destructor
method, and this method is simply empty. How is the original object actually
being deleted? I can only assume the delete operator calls the destructor
method and then deletes the original object (outside of the destructor),
which you don't explicitly do yourself.
...

If the destructor method is really "simply empty" then the only thing
you need to do to destroy the object is to free the memory it occupies.
That's exactly what delete-expression does after calling the object's
destructor: it frees the memory by calling the appropriate function
'operator delete'. Where exactly do you see the endless loop here?

 

[Andrey Tarasevich]

incorrect. as indicated in statement 1. an object's (dynamically created
...meaning HEAP) destructor is called when the object goes out of scope.
...

The first statement in your original post does not indicate anything. It
is terminologically incorrect and, therefore, it is completely meaningless.

 

[Andrey Tarasevich]

...
1) dynamically created objects do not call their destructors when they go
out of scope - only for objects on the stack. OR

C++ has no concept of "objects calling their destructors", no matter
what these objects are: static, local, dynamic, "on stack", etc.

2) default destructor of pointers to dynamically created objects are called
when they go out of scope.

Firstly, C++ has no concept of "default destructor". Secondly, pointers
are object of non-class types. The have no destructors at all. Nothing
is called.

 

[John Harrison]

Tried it, and you are right.

Either:

1) dynamically created objects do not call their destructors when they go
out of scope - only for objects on the stack. OR
2) default destructor of pointers to dynamically created objects are called
when they go out of scope.

So is it 1 or 2? who knows.

1 is closer to the truth, but you have to get clear in your head the
difference between the pointer to the dynamic object, and the object itself.

The pointer does go out of scope because it is on the stack, but the pointer
going out of scope has no effect at all on the dynamic object.

The dynamically created object never goes out of scope, it has no scope, it
only becomes invalid when it is deleted.

john

 

[Ron Natalie]

built-in types have 'trivial destructors'. (That's what the standard
calls them.)

No, sorrry. They don't and the standard doesn't call them that. Trivial constructors
exist only for class type. Trivial constructors are a subset of the implicitly declared
default constructor which is also only exists for classes.

Non-classes don't have constructors or destructors as they don't have member
functions at all. You can (mostly for the convenience of template program),
use the syntax of a destructor call on a non-class type, but there really is no
underlying destructor, it's a special syntax of the . and -> operators.

Note to other posters - nothing in the standard requires
they 'don't do anything' - it would be permissible for int's
destructor to set the bytes it occupied to '0xDEADBEEF' or
'0xCDCDCDCD' -

int does NOT have a destructor.

 

[Default User]

Pointers are not objects.

Sure they are. They just aren't objects of the type they point to.




Brian Rodenborn

 

[Andrey Tarasevich]

built-in types have 'trivial destructors'. (That's what the standard
calls them.)

No. Built-in types have no destructors at all. The standard never makes
any mention of built-in types having any destructors. Only class types
have destructors. Built-in types are not class types.

The definition of 'trivial destructor' is given in 12.4/3 and, as could
be expected, it is applicable to class types only.

Note to other posters - nothing in the standard requires
they 'don't do anything' - it would be permissible for int's
destructor to set the bytes it occupied to '0xDEADBEEF' or
'0xCDCDCDCD' - and for a debugging implementation of C++, that
would even be desirable.

The bytes can be set to anything, you are right. But it has nothing to
do with any destructors. Type 'int' is not a class type and, therefore,
it has no destructor at all.

The standard does define 'trivial
destructors' in such a way as to *allow* a trivial destructor to
do nothing, but there's no requirement.

That's true. But, once again, the notion of 'destruction' is not
applicable to non-class types.