Re: Avoiding dangling pointers.

On Apr 11, 2:33 pm, Rafael Anschau <rafael.ansc...@[EMAIL PROTECTED]
> wrote:
> I read that you should assign null (0) to all pointers that you call
> delete on.
>
> Does that mean:
>
> *p=0(set the value pointed to to 0).
>
> or
>
> p=0(set the address held to zero).
>
> The last one is awkward for none would want a pointer pointing
> to address zero(even though it compiles fine, you can´t assign
> anything to it).
>
> I find the first still awkward(though less than the seccond) for I
> would assume you shouldn´t
> assign values to places you no longer use.

i would say both methods are suboptimal

the point for this idiom
   is that behavior must change depending on state
   (presence or absence of pointer means different actions needed)

in c++
   this should be relegated to RAII preserving state machines
   and the only (smart) pointers dealt with
     should be the pointers to current state

one of the earliest
(and still one of the most im****tant)
   language features that made c++ a "better c"
is RAII and the ability to set up
automated state entry and leaving actions
   (ctors and dtors)

lifetime management should always fall into one of four cl*****:
   - tem****ary / anonymous / expression
   - block (automatic) scope
   - a state lifetime
   - global / application

(one could make another distinction on message lifetimes
    since it is common to need to pass messages across thread
boundaries
    but discard them once processing is done
  but here the message queues play the role of state machines
  both informally and purely formally)

the only one that requires heap allocation is state lifetime
   which should be created by some transition event on entry
   and deleted by exiting the state

the state objects should contain anything with the lifetime of the
state
   and thus can always assume their presence

this fixes all problems with zombie objects
and separates out behaviors to only work with valid memory

using
   if (p) doSomethingWithP(p);
everywhere p is used
is exactly the same as
   if (inStateX) doSomethingRelatedToStateX();

ie.
   - it is error prone
   - leaving actions are not automated
   - it is error prone
   - it is procedural and interleaves behaviors
and
   - it is error prone

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar


-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]