🚀 go-pugleaf

In article <AD9409799668E161@sleipner.nts.mh.se> lars.farm@nts.mh.se
(Lars Farm) writes:
>In article <KANZE.96Apr10111407@gabi.gabi-soft.fr>,
>kanze@gabi-soft.fr (J. Kanze) wrote:
>
>>I believe that John Skaller had a proposal with something like six
>>different pointer types.  The committee found this a little too
>
>He said a while ago that he proposed two classes(*). (1) auto_ptr for
>lifetime control within a block (no copy/assign) and (2) a ref counted
>class for shared objects. There is a need for both but only one was
>accepted and that is the real problem.
>
>
>auto_ptr<> is slowly being mutated into a mixture of the two classes. It
>has moved away from its original goal and is becoming a cheap shared_ptr<>.
>This requires very strange and disturbing use of op=/copy.

Yes, auto_ptr has evolved.  I don't find that strange or disturbing.

>
>void f( auto_ptr<X> x ) { ...will delete x }
>
>  // promise: x const, x will _not_ change, x will _not_ become invalid

It is indeed a shame that all this promise cannot be kept for auto_ptr.  
If someone can work out a change to the base language to allow for non-const
copy operations, make sure that it doesn't break anything else, work out
exact wording for the working paper, and convince the committee to accept
the change, then I would gladly propose going back to an auto_ptr with
non-const copy operations. 

Note that the promise of not becoming invalid cannot be kept for f(const X*)
either.

>void g( const auto_ptr<X>&x ) {
>  // ... x ok
>  f(x);
>  // ... oops
>}
>void h() {
>   auto_ptr<X> p( new X );
>   // p valid
>   g(x);
>   // p bad. Undetected by the compiler because the standard 
>   // library class auto_ptr subverted the C++ type system
>}
>
>IMHO the only reasonable solution is to have two classes. If the committee
>only accepts one then users will have to write the other. That's ok, as
>long as it is obvious that auto_ptr isn't a general purpose smart_ptr. With

IMHO the only general purpose smart pointer is a garbage collected smart
pointer, which auto_ptr obviously is not.

>the current weird auto_ptr copy/op= perhaps users will have to write both
>the original and the ref counted class on their own. Or worse, they will
>actually use auto_ptr as if it was the rejected ref_counted ptr. This is a
>reasonable assumption because auto_ptr is the only standard smart ptr and
>users should be allowed to assume it is safe. It would be safe with private
>op=/copy as the original.

The original auto_ptr was so limited that important uses would require
the use of raw pointers and boolean flags, which are much less safe
techniques than the current auto_ptr.  So you would need a counted_ptr
for those uses, but the overhead of counted_ptr is just too high. We
gave auto_ptr just enough copy semantics to support passing them to
functions and returning them from functions. As a result, it becomes
possible to use auto_ptr for some less safe idioms as well.  Given the
infinity of unsafe idioms that C++ allows I just don't see the
problem.

>
>When designing a class for mass consumption it should not only support the
>intended idioms. It should also prevent missuse in common situations. The
>original does that. The current auto_ptr doesn't.
>

>Please reconsider John Max Skallers original proposal.
>
>(*) he has also mentioned other smart pointers here. holding arrays -
>block/ref-counted. copying pointers and cloning pointers using varying
>implementation techniques but AFAIK they were never proposed as standard
>classes.
>

I don't recall Max making such a proposal, though he made many
contributions to our discussion of smart pointers.  I can assure you
that I would not insult the committee by asking them to reconsider a
proposal that they have rejected more than once already.

Greg Colvin
gregor@netcom.com
---
[ 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                             ]