Hi Christian,
> Well, as the attached (expanded) example show, it does call the DTOR
> of class C1. For what ever reason, the underlying TObject array is
> still there :-(. This seems extreemly odd. The program should
> SIGSEGV.
I supposed you meant that the C1 object in C2 seems to still be there.
This is actually a behavior that __might__ happen under standard C++ rule.
When you delete an object, its destructor is executed and its memory is
marked as free to be reused. UNLESS this memory is actually reused (by
some new memory allocation for example), the memory where the object
used to be is still in the exact same state as at the end of the destructor.
Thus it is very often the case that just after 'delete myobject;' you can
still use it without segmentation fault (however, there is no guarantee of
that).
As you probably know, in your example the test:
C1* c1 = c2->GetC1();
if (!c1)
is guaranted to always say that c1 is still there, since (in the small program
you sent) there is NO provision for c2 to learn of the demise of C1.
Cheers,
Philippe
-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Christian Holm
Christensen
Sent: Tuesday, November 20, 2001 2:10 PM
To: roottalk@pcroot.cern.ch
Subject: Re: [ROOT] Little hint about pointers
Hi all,
I didn't get this message to roottalk, so here goes.
Hi Alberto,
On Tue, 20 Nov 2001 16:11:19 +0100
Alberto Pulvirenti <alberto.pulvirenti@CT.INFN.IT> wrote
concerning "Re: [ROOT] Little hint about pointers":
> Ok, Chhristian, I saw you're right.
> But now rises another question:
>
> if I leave the C2 destructor void, and I invoke the TObjArray::Delete(),
> what will happen to the object pointed by the C2 ? It seems that the
> TObjArray::Delete doesn't remove it...
Well, as the attached (expanded) example show, it does call the DTOR
of class C1. For what ever reason, the underlying TObject array is
still there :-(. This seems extreemly odd. The program should
SIGSEGV.
I tried this on Red Hat 6.2 (GCC 2.91) and Red Hat 7.1 ('GCC 2.96')
using ROOT 3.02/00. I also tried on Red Hat 6.2 and ROOT 3.02/04 with
the same result.
However, on Debian GNU/Linux 2.1 (GCC 2.91) with ROOT 2.23/10, the
program does get a SIGSEGV, as I believe it should.
Maybe I've misunderstood something in the ANSI/ISO C++ standard, that
makes this behaviour alright, but I dont think so. I believe this is a
question for the ROOT team.
It seems that one gets a handle to the newly allocated TObjects
resulting from TObjArray::Init in TObjArray::Delete. That's my guess
anyway.
This issues, I believe goes for all subclasses of TCollection,
including THashList.
Yours,
Christian Holm Christensen -------------------------------------------
Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
DK-2200 Copenhagen N Cell: (+45) 28 82 16 23
Denmark Office: (+45) 353 25 305
Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:09 MET