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
52  26872 
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
"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
"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 Destructor would be called only for the object created on the heap.
I meant stack ofcourse ;-).
> "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 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
> > 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
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 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.
"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
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
"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
"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
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
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
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. 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 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
> >
> 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
> 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
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.
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.
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 > > > 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
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
> 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
"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.
"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?
"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.
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
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
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
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
> 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
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.
"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.
"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.
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
jeffc wrote: Pointers are not objects.
Sure they are. They just aren't objects of the type they point to.
Brian Rodenborn
"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.
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
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
"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.
"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.
"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.
"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.)
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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Alexander Stippler |
last post by:
Hi,
I have some question about the usage of delete. I have some reference
counted classes, all derived from SharedObject. It's destructor looks like
this:
~SharedObject()
{
if...
|
by: Stub |
last post by:
Please answer my questions below - thanks!
1. Why "Derived constructor" is called but "Derived destructor" not in Case
1 since object B is new'ed from Derived class?
2. Why "Derived destructor"...
|
by: Timothy Madden |
last post by:
Hello
I have a linked list of object of a class. I thought it would be nice to
have the destructor delete the whole list when I delete just the first
element. I don't want to recursivly destroy...
|
by: frs |
last post by:
For memory economization, I need to get rid if the virtual
destructor. Under this constraint I get caught up in a design,
where I need to call a destructor of a derived class from a
base class....
|
by: Peter Oliphant |
last post by:
I'm programming in VS C++.NET 2005 using cli:/pure syntax. In my code I have
a class derived from Form that creates an instance of one of my custom
classes via gcnew and stores the pointer in a...
|
by: |
last post by:
Hi,
From 11.11 here, I know that member objects get their dtor's called autmatically:
http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.11
What if I have a pointer to a member object?...
|
by: junw2000 |
last post by:
I use the code below to study delete and destructor.
#include <iostream>
using namespace std;
struct A {
virtual ~A() { cout << "~A()" << endl; }; //LINE1
void operator delete(void* p) {...
|
by: Ben Voigt |
last post by:
I have a POD type with a private destructor. There are a whole hierarchy of
derived POD types, all meant to be freed using a public member function
Destroy in the base class. I get warning C4624....
|
by: rohits123 |
last post by:
I have an overload delete operator as below
//////////////////////////////////
void operator delete(void* mem,int head_type) {
mmHead local_Head = CPRMemory::GetMemoryHead(head_type);...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
| |
