By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,610 Members | 1,989 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,610 IT Pros & Developers. It's quick & easy.

C++: destructor and delete

P: n/a
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....)

Any comments appreciated.

asasas

Jul 19 '05 #1
Share this Question
Share on Google+
52 Replies


P: n/a
Where are these statements from?
You have to differentiate between objects created dynamically on the heap
with the 'new' operator, and objects created on the stack in a scope.
Using the delete operator instructs the program to call the destructor of
the class and then free the memory for the object. Objects that simply go
out of scope implicitely have the same process performed on them.
"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
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....)

Any comments appreciated.

asasas

Jul 19 '05 #2

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
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....)

Any comments appreciated.

asasas


Destructor does not call delete, so there is no loop.

john
Jul 19 '05 #3

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
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.
Consider this code -

#include <iostream>
class A{
public:
A()
{
}
~A()
{
std::cout << "Inside D'tor";
}
};

void f()
{
A a;
A *ptrA = new A;
}

int main ()
{
f ();
}

If you mean that when f() returns two destructors will be called then it's
wrong.
Destructor would be called only for the object created on the heap.
In fact this is a memory leak.

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

That's true.

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....)

Destructor does not call delete unless in your destructor you write -
delete this;

HTH,
J.Schafer
Jul 19 '05 #4

P: n/a
Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).
Jul 19 '05 #5

P: n/a
> "Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
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....)

Any comments appreciated.

asasas


Destructor does not call delete, so there is no loop.

john


Generally speaking, you have a delete in a destructor method. That said, a
delete calls the destructor and the endless cycles continues. I'm sure there
is something im missing.
sasas
Jul 19 '05 #6

P: n/a

Where are these statements from?
You have to differentiate between objects created dynamically on the heap
with the 'new' operator, and objects created on the stack in a scope.
Using the delete operator instructs the program to call the destructor of
the class and then free the memory for the object.


and whats USUALLY in the destructor method? a delete statement also,and
hence the loop.
sasasasas
Jul 19 '05 #7

P: n/a
> > Destructor does not call delete, so there is no loop.
Generally speaking, you have a delete in a destructor method. That

said, a delete calls the destructor and the endless cycles continues. I'm sure there is something im missing.


A destructor never calls the delete operator on itself (this), hence no
endless loop. In a destructor the delete operator (if any) is only used
for other objects owned by that class instance, not for itself.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


Jul 19 '05 #8

P: n/a
Newsnet Customer wrote:
Where are these statements from?
You have to differentiate between objects created dynamically on the heap
with the 'new' operator, and objects created on the stack in a scope.
Using the delete operator instructs the program to call the destructor of
the class and then free the memory for the object.

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


What loop?

delete statements can often be found in destructors, but they
do not target the object whose destructor it is.

S

Jul 19 '05 #9

P: n/a


Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).


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

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...


Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).


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


Why don't you run the code I posted and see for yourself if the destructor
gets called.
--
JS
Jul 19 '05 #11

P: n/a


Newsnet Customer wrote:

Hi,

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

A dynamically created local object ...

int main()
{
std::string *p;

p = new std::string;

.... calls it's destructor method when it goes out of scope

well. p goes out of scope. But that does not mean, that the
dynamically created object, where p points to is destroyed.
Agree.

Statement 2: "A dynamically created object will call it's destructor when it
is made a target of a delete".
p = new std::string;

...

delete p;

the string which is pointed to by p is destroyed.

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....)


Why should this happen?

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 19 '05 #12

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
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....)

Any comments appreciated.

asasas


Destructor does not call delete, so there is no loop.

john


Generally speaking, you have a delete in a destructor method. That said, a
delete calls the destructor and the endless cycles continues. I'm sure

there is something im missing.


Sometimes you delete a subobject in the destructor. You don't delete the
original object.

class X
{
~X()
{
delete ptr; // delete Y object, calls Y destructor
}
Y* ptr;
};

X* p = new X;
delete p; // deletes an X object, calls X destructor

The only way there would be a loop was if you did 'delete this' in the
destructor.

john
Jul 19 '05 #13

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...


Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).


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


No it is not.

{
X* ptr = new X;
}

No destructors are called in the above code, because POINTERS do not have
destructors. ptr is a POINTER to X, its is not an X.

{
X x;
}

X destructor is called (assuming it has one).

You're very cocky considering, by your own admission, you don't get it.

john
Jul 19 '05 #14

P: n/a


Newsnet Customer wrote:
Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).


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


The point is: a dynamically created object(that means on the heap) *never*
goes out of scope. The object is destroyed when you explicitely say so
with the help of delete.

{
std::string* p;
p = new std::string;
}

At this point, p goes out of scope and hence is destroyed.
But the dynamically allocated string object lives on, even
if there is no means to access it any longer.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 19 '05 #15

P: n/a
Newsnet Customer wrote:
Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).

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


You misunderstand the definition of stack and heap. The word "stack"
used in this context is usually speaking of the stack frame. The stack
frame is a segment of memory, which also happens to be part of a larger
stack, which is used to contain return information as well as local
variables. When the function returns (or scope is lost on these stack
items) then the system esentially calls "delete" on all local variables.

The heap is just the main memory block. You request segments of this
heap be allocated to your program by using calls such as new or malloc.
You must give this memory back to the system when you are done.

There is very little difference in the actual objects contained within
the stack and heap. They all look the same. The only difference is
that stack objects are returned by the process automagically whereas
heap items must be returned by the programmer. Another difference is
that you refer to heap items based on a variable contained in the stack
- these are pointers.

If, as you say, there was an endless loop in calling delete on a heap
item then it would also occur in the stack since both methods call the
destructor. If the destructor deletes the object being deleted then
things blow up no matter where in memory that object is.

NR

Jul 19 '05 #16

P: n/a
Newsnet Customer wrote:
Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).

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


Your first statement was incorrect. Josephine is correct.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #17

P: n/a
Sometimes you delete a subobject in the destructor. You don't delete the
original object.

class X
{
~X()
{
delete ptr; // delete Y object, calls Y destructor
}
Y* ptr;
};

X* p = new X;
delete p; // deletes an X object, calls X destructor

The only way there would be a loop was if you did 'delete this' in the
destructor.

john


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


Jul 19 '05 #18

P: n/a
Newsnet Customer wrote:

Hi,

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


A dynamically created local object ...

int main()
{
std::string *p;

p = new std::string;

... calls it's destructor method when it goes out of scope

well. p goes out of scope. But that does not mean, that the
dynamically created object, where p points to is destroyed.

Right. That means the destructor method only performs "house keeping" and
memory management of other objects/subjects and never memory mamagement on
itself (this).

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


p = new std::string;

...

delete p;

the string which is pointed to by p is destroyed.

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....)


Why should this happen?


Well it shouldn't now that i know that the destuctor never calls delete on
itself (this).

Thanks, you cleared up my misunderstandings.
assasas


Jul 19 '05 #19

P: n/a
> >

> Destructor would be called only for the object created on the heap.

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


No it is not.

{
X* ptr = new X;
}

No destructors are called in the above code, because POINTERS do not have
destructors. ptr is a POINTER to X, its is not an X.


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.

{
X x;
}

X destructor is called (assuming it has one).
An object will always have a constructor and a destructor. If either is not
defined, they will be created for you implicitly. Since pointers are objects
too, they will have a constructor and destructor.
You're very cocky considering, by your own admission, you don't get it.

john


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.
sasasas

Jul 19 '05 #20

P: n/a
>
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
Jul 19 '05 #21

P: n/a
Newsnet Customer wrote:

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #22

P: n/a
Newsnet Customer wrote:

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

No it is not.

{
X* ptr = new X;
}

No destructors are called in the above code, because POINTERS do not have
destructors. ptr is a POINTER to X, its is not an X.

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.

{
X x;
}

X destructor is called (assuming it has one).

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.

You're very cocky considering, by your own admission, you don't get it.

john

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #23

P: n/a


Newsnet Customer wrote:

> > Destructor would be called only for the object created on the heap.
>
> I meant stack ofcourse ;-).

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

No it is not.

{
X* ptr = new X;
}

No destructors are called in the above code, because POINTERS do not have
destructors. ptr is a POINTER to X, its is not an X.


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.
{
X x;
}

X destructor is called (assuming it has one).
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.
You're very cocky considering, by your own admission, you don't get it.

john


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.

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 19 '05 #24

P: n/a
> > > Destructor would be called only for the object created on the heap. > >
> > I meant stack ofcourse ;-).
>
> incorrect. as indicated in statement 1. an object's (dynamically created > ...meaning HEAP) destructor is called when the object goes out of scope. >

No it is not.

{
X* ptr = new X;
}

No destructors are called in the above code, because POINTERS do not have destructors. ptr is a POINTER to X, its is not an X.
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 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.

X destructor is called (assuming it has one).


An object will always have a constructor and a destructor. If either is

not
defined, they will be created for you implicitly. Since pointers are

objects
too, they will have a constructor and destructor.


OK, you can put it like that. But a pointer has a destructor WHICH DOES
NOTHING. It does not call delete.
You're very cocky considering, by your own admission, you don't get it.
john


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.


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


Jul 19 '05 #25

P: n/a
On Tue, 02 Sep 2003 18:35:30 +0930, Newsnet Customer wrote:
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
Jul 19 '05 #26

P: n/a
> 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.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

Jul 19 '05 #27

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...
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.
Jul 19 '05 #28

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...

Where are these statements from?
You have to differentiate between objects created dynamically on the heap with the 'new' operator, and objects created on the stack in a scope.
Using the delete operator instructs the program to call the destructor of the class and then free the memory for the object.


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


Where did you get that idea?
Jul 19 '05 #29

P: n/a

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...

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.
Jul 19 '05 #30

P: n/a
Newsnet Customer wrote:
...
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?

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #31

P: n/a
Newsnet Customer wrote:
Sometimes you delete a subobject in the destructor. You don't delete the
original object.

class X
{
~X()
{
delete ptr; // delete Y object, calls Y destructor
}
Y* ptr;
};

X* p = new X;
delete p; // deletes an X object, calls X destructor

The only way there would be a loop was if you did 'delete this' in the
destructor.

john


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?

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #32

P: n/a
Newsnet Customer wrote:
> Destructor would be called only for the object created on the heap.


I meant stack ofcourse ;-).


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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #33

P: n/a
Newsnet Customer wrote:
...
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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #34

P: n/a
>
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
Jul 19 '05 #35

P: n/a
Newsnet Customer wrote:


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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #36

P: n/a
"Newsnet Customer" <ni********@iprimus.com.au> writes:
>
>
>
> > > Destructor would be called only for the object created on the heap.
> >
> > I meant stack ofcourse ;-).
>
> incorrect. as indicated in statement 1. an object's (dynamically created
> ...meaning HEAP) destructor is called when the object goes out of scope.
>
No it is not.

{
X* ptr = new X;
}

No destructors are called in the above code, because POINTERS do not have
destructors. ptr is a POINTER to X, its is not an X.


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.

{
X x;
}

X destructor is called (assuming it has one).


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.
Jul 19 '05 #37

P: n/a

"llewelly" <ll*********@xmission.dot.com> wrote in message news:86************@Zorthluthik.local.bar...
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.)


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.
Jul 19 '05 #38

P: n/a
llewelly wrote:
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.)


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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #39

P: n/a
jeffc wrote:
Pointers are not objects.

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


Brian Rodenborn
Jul 19 '05 #40

P: n/a

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...
jeffc wrote:
Pointers are not objects.


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


No, not any more than ints are objects. In the context of this discussion,
that ain't happenin'. No one mentioned "smart pointers" or anything fancy,
either.
Jul 19 '05 #41

P: n/a
jeffc wrote:
> Pointers are not objects.


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


No, not any more than ints are objects. In the context of this discussion,
that ain't happenin'. No one mentioned "smart pointers" or anything fancy,
either.


It looks like your idea of an "object" is significantly different from
the standard meaning of the term "object" in C++. Ints are objects.
Pointers are objects too.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #42

P: n/a


Andrey Tarasevich wrote:

jeffc wrote:

> Pointers are not objects.

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


No, not any more than ints are objects. In the context of this discussion,
that ain't happenin'. No one mentioned "smart pointers" or anything fancy,
either.


It looks like your idea of an "object" is significantly different from
the standard meaning of the term "object" in C++. Ints are objects.
Pointers are objects too.


But you agree that they are radically different to class objects?

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 19 '05 #43

P: n/a

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...
jeffc wrote:
Pointers are not objects.


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


No, not any more than ints are objects. In the context of this discussion,


The context of the discussion is C++. int's are objects, so are pointers.
Jul 19 '05 #44

P: n/a

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...
jeffc wrote:

> Pointers are not objects.

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


No, not any more than ints are objects. In the context of this

discussion,
The context of the discussion is C++. int's are objects, so are

pointers.

Not good enough. There is a clear distinction between a built in type and
an instance of a class.
Jul 19 '05 #45

P: n/a

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...
..

Not good enough. There is a clear distinction between a built in type and
an instance of a class.

There is. But they are both, as far as C++ is concerned, objects.
Object is a term defined in the language as "a region of storage."
It is essentially any "data" code (that is, functions and pieces thereof)
are not objects, everything else is.

Objects are NOT limitted to classes.
Jul 19 '05 #46

P: n/a

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...

"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net... .

Not good enough. There is a clear distinction between a built in type and an instance of a class.
There is. But they are both, as far as C++ is concerned, objects.
Object is a term defined in the language as "a region of storage."
It is essentially any "data" code (that is, functions and pieces thereof)
are not objects, everything else is.

Objects are NOT limitted to classes.


Fine Ron, be pedantic if you insist. Stroustrup calls that a "simple and
low-level notion of an object" and warns not to confuse it with the notion
of a class object, which is what you've done - confuse things. Here's the
original quote from the OP:

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


You go ahead and correct him and I'm sure you can come up with something
better than I did (I'm at a loss as to why you'd argue with my reply, rather
than with his statement.)
Jul 19 '05 #47

P: n/a
jeffc wrote:
> >
> > > Pointers are not objects.
> >
> > Sure they are. They just aren't objects of the type they point to.
>
> No, not any more than ints are objects. In the context of this

discussion,

The context of the discussion is C++. int's are objects, so are

pointers.

Not good enough. There is a clear distinction between a built in type and
an instance of a class.
...


Yes, there is. But I don't see how it is supposed to prove your point.
You were talking about "objects". Now your are talking about "built-in
types" and "instances of a class". Where is the connection?

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #48

P: n/a
jeffc wrote:
...
Fine Ron, be pedantic if you insist. Stroustrup calls that a "simple and
low-level notion of an object" and warns not to confuse it with the notion
of a class object, which is what you've done - confuse things. Here's the
original quote from the OP:

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

objects
too, they will have a constructor and destructor."


You go ahead and correct him and I'm sure you can come up with something
better than I did (I'm at a loss as to why you'd argue with my reply, rather
than with his statement.)
...


It's been said many times here and in many other places, that TC++PL
book uses alternative non-standard terminology. Formally speaking, from
the standard C++ point of view, the above statement and a number of
other statements made in TC++PL are _completely_ _incorrect_.

It is not a matter of "correcting" or "not correcting" Mr. Stroustrup.
It is a matter of understanding that the author probably had his reasons
to deviate from the standard terminology. It should be kept in mind when
reading the book.

This forum, by default, uses the standard terminology. If you prefer to
use the one from TC++PL, you should accompany you messages with the
corresponding remark, to avoid unnecessary confusion.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #49

P: n/a
Karl Heinz Buchegger wrote:
>> ...
>> > Pointers are not objects.
>>
>> Sure they are. They just aren't objects of the type they point to.
>
> No, not any more than ints are objects. In the context of this discussion,
> that ain't happenin'. No one mentioned "smart pointers" or anything fancy,
> either.


It looks like your idea of an "object" is significantly different from
the standard meaning of the term "object" in C++. Ints are objects.
Pointers are objects too.


But you agree that they are radically different to class objects?


Of course, I do. If by "class objects" you mean "class instances" or
"objects of class type".

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #50

52 Replies

This discussion thread is closed

Replies have been disabled for this discussion.