A few questions on auto_ptr.

First of all, is the auto_ptr defined in the May 1996 DWP (which I have
not seen, but which (the auto_ptr) is described on the More Effective C++
webpage) the final word in auto_ptr?  Or is it still being worked on?

Also, is there any comment in the latest drafts of the DWP on users
calling release() on an auto_ptr?  Seems to me that this may result in
undefined behavior (ie a memory leak) if it is done to an auto_ptr which
has ownership of the pointed-to object.  Would a comment to this effect in
the standard be worthwhile?

Also, is there any other reason which the semantics of auto_ptr were
changed from "only one may point to an object" to "many may point to but
only one may own an object", besides the problem with returning an
auto_ptr from a function?  Both semantcs can lead to undefined behavior if
abused; it seems to me that the prior semantics will cause more immediate
symptoms to appear if abuse occurs (in other words, the consequences of
dereferencing null ooposed to the consequences of dereferencing a pointer
which points to garbage), making debugging such abuse easier.

(Not to mention the annoyance of the extra bit needed to deal with
ownership......:) )

Scott

--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On Fri, 6 Sep 1996, john (j.d.) hickin wrote:

> >>(Not to mention the annoyance of the extra bit needed to deal with
> >>ownership......:) )
>
> In fact the version I saw (and use) has a mutable bool owner data member
> which means that the size on a 32 bit machine is now 8 bytes!  I preferred
> the original which could have been modified to make the pointer mutable
> and saved 4 bytes.

Many implementations, it seems, may solve this problem by taking advantage
of the fact that new on most architectures returns an address which is
longword-aligned..and stuffing the owner bit in the lower two bits of the
pointer!!!!!

I suppose if the compiler provides the auto_ptr implementation, this won't
hurt too much.  A user-implemented auto pointer, on the other hand, would
have to have an UNGODLY amount of reinterpret_casts to pull this
gross klu^H^H^H^H^H^H^H^H^Hclever trick off.

Which would likely make a user-defined auto_ptr non-portable.  Unless the
implementor bites the bullet and uses a bool...

Of course, for auto_ptrs declared as an automatic variable, the extra four
bytes on the stack likely won't make a big difference.  For auto_ptrs
declared in a class (in order to make sure that if a constructor
terminates with an exception, allocated objects will be destructed
properly)...these extra four bytes might matter, especially if the class
footprint is otherwise small, and/or there will be a lot of class
instances declared.  (At my place of employment, I design and write
software for embedded instruments, which often have tight resource
requirements.  So I do think about these things....)

> I believe the design is motivated by the desire to force the use of auto_ptr
> to be correct *by design*.  In the implementation that i took from the net
> it was not possible to query the owner flag: it was provate and there was no
> accessor function.  In the approach where the pointer value codes for ownership
> as well as for referencing the owned object it is very easy to infer ownership:
>
>  if ( ptr.get() != 0 ) // ptr is owner
>
> Now the above trick can't be used.  I agree with Colvin'a design but I am
> unhappy with its consequences on the auto_ptr's size.

My general beef is the following:  Consider this code.

class bar;

void foo (void)
{
    auto_ptr<bar> a = new bar;
    auto_ptr<bar> b;

    b=a;
    bar c = *b;
    b=0;
    c=*a;
}

This code, obviously, contains a major bug; namely dereferencing a.  If
the old auto_ptr is used, the result is a null dereference, an immediate
crash, and the developer will probably be able to find it.  If the NEW
auto_ptr is used, c now contains garbage.  If the user is lucky, the copy
operator will crash.  If the user is unlucky...the effects won't be seen
for quite a while.

A similar problem occurs when an auto_ptr is passed by value to a
function.  This is risky...but in the case where the intent is for the
called function to own the storage and delete it when it finishes, this is
useful.  But if the calling function then dereferences the auto_ptr after
the function call, we have the same quandry as above:  Should this be easy
to diagnose, or hard?


Scott

/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>(Not to mention the annoyance of the extra bit needed to deal with
>>ownership......:) )

In fact the version I saw (and use) has a mutable bool owner data member
which means that the size on a 32 bit machine is now 8 bytes!  I preferred
the original which could have been modified to make the pointer mutable
and saved 4 bytes.

I believe the design is motivated by the desire to force the use of auto_ptr
to be correct *by design*.  In the implementation that i took from the net
it was not possible to query the owner flag: it was provate and there was no
accessor function.  In the approach where the pointer value codes for ownership
as well as for referencing the owned object it is very easy to infer ownership:

 if ( ptr.get() != 0 ) // ptr is owner

Now the above trick can't be used.  I agree with Colvin'a design but I am
unhappy with its consequences on the auto_ptr's size.



--
John Hickin      Nortel Technology, Montreal, Quebec
(514) 765-7924   hickin@nortel.ca