Problem with list.

[Aseem Rastogi]

Thanks for your reply ElJay.

What puzzled me is that if I do

A* b = a;

delete b;

a->foo ();       //This gave me a segmentation fault.

Your explaination helps. But, can I be sure that the memory assigned to 
'a' in first place from heap has been freed and if required by some 
other application it will be available with kernel?

Thanks,

Regards,
Aseem.

John Love-Jensen wrote:

>Hi Aseem,
>
>>Can somebody explain the following behaviour?
>>
>
>After you relinquish a pointer to l list, you continue to hold onto the
>pointer in a.
>
>When the A object in l list is deleted, the a pointer is left with a
>dangling reference.
>
>A dangling reference is not guaranteed to cause a segmentation fault when
>dereferenced.  It appears that the heap still had the "ghost" of the A
>object, which the a pointer accessed -- but it could have also caused a seg
>fault.  The behavior is undefined.
>
>There are several strategies you can employ to help you catch programming
>mistakes like this.
>
>One is to use a heap manager that scrubs all released memory to some garbage
>value.  0xDEADBEEF is a common choice, since it is conspicuous in a
>debugger.  You probably wouldn't want that overhead in production code, but
>for diagnostic purposes it can be quite handy.
>
>Another strategy is to use managed pointers, such as std::auto_ptr or one of
>the various managed pointed in Boost, which will explicitly relinquish
>ownership.
>
>Another strategy is to use a third party product to help detect this kind of
>situation.  Such as Electric Fence, ValGrind, IBM Rational Purify &
>Quantify, or Nu-Mega Technologies Bounds Checker... just to name a few.
>There are a lot out there.
>
>q.v. http://www.sdmagazine.com/jolts/prev_utl.htm
>
>HTH,
>--Eljay
>
>


-- 
The end is always good. If it's not good, it's not the end.