My answer sounded too personal and I apologize if it was taken that
way. Of course it is viable to discuss whether the committee's choice
on smart pointer implementation is the best possible. You can probably
tell that I am one of those people who believe, in this case and in C++
in general, that freedom and flexibility should override most all other
considerations. BTW I am a C++ computer consultant and I have had to
maintain innumerable pieces of code written by others that did not make
me feel necessarily joyous and healthy<g>.

Andrew Bell wrote:

> On 01 Feb 98 13:41:36 GMT, Edward Diener <eddielee@abraxis.com> wrote:
> >I am always amused by people who know some C++ telling me how
> >complicated the language is with templates, exceptions, multiple
> >inheritance et al. but when I say to them to just not use the features
> >they don't understand that usually ends the discussion pretty fast.
>
> Uh, maybe they have to maintain code written by other people who do
> understand the feature, or at least think they do?  Almost every
> significant program these days is written by a team of programmers.
>
> There are a variety of ways smart pointers could work, with ownership
> flags, ref counting, etc.  The committee ended up with one choice,
> perhaps the most flexible choice, but not necessarily the safest.
> Whether this was the best one, or whether it would have been better to
> have several smart pointers with multiple idioms is a reasonable point
> to debate.  Pointless perhaps, given that it isn't worth changing the
> standard for, but still interesting to debate.
>
> Also, it's worth discussing simply to understand exactly what auto_ptr
> is supposed to do, and what situations it isn't well-suited 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 01 Feb 98 13:41:36 GMT, Edward Diener <eddielee@abraxis.com> wrote:
>I am always amused by people who know some C++ telling me how
>complicated the language is with templates, exceptions, multiple
>inheritance et al. but when I say to them to just not use the features
>they don't understand that usually ends the discussion pretty fast.

Uh, maybe they have to maintain code written by other people who do
understand the feature, or at least think they do?  Almost every
significant program these days is written by a team of programmers.

There are a variety of ways smart pointers could work, with ownership
flags, ref counting, etc.  The committee ended up with one choice,
perhaps the most flexible choice, but not necessarily the safest.
Whether this was the best one, or whether it would have been better to
have several smart pointers with multiple idioms is a reasonable point
to debate.  Pointless perhaps, given that it isn't worth changing the
standard for, but still interesting to debate.

Also, it's worth discussing simply to understand exactly what auto_ptr
is supposed to do, and what situations it isn't well-suited for.

Andrew Bell
abell8920@mindspring.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                             ]

Philippe Nobili wrote in message <34D1FC4F.AF5@imaginet.fr>...
>C* c = new C() ;
>auto_ptr<C> pC(c) ;
>{
> auto_ptr<C> pC2 = pC ;
>}
>....
>
>Here, ownership is transfered to 'pC2', which is deleted -- and its C
>instance with it -- at the end of its scope. We end up with 'pC' owning
>a dangling pointer.

auto_ptr has changed since CD2.  After pC2 has been constructed, pC.get()
will return zero.  'c', of course, will still be dangling.

It is easy to misuse many of the language, and library features of C++.  I
believe auto_ptr can be a useful tool.  In other situations you may prefer
reference counting.
---
[ 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
]

The fact that a class, or template if you will, can be misused is
certainly no reason to not include it as part of the standard library.
I find auto_ptrs to be immensely useful, especially in exception
unwinding conditions. Your example below is well known and is
essentially no different from

C* c = new C() ;
{
C* d = c;
delete d;
}

except that in my case the programming error can be seen much more
easily. Since the specification for transfer of ownership the pointer
in auto_ptrs is clear and simple any user of auto_ptr should understand
what is going on. If he or she does not understand the transfer of
ownership concept, then auto_ptr should not be used by that individual.
I am always amused by people who know some C++ telling me how
complicated the language is with templates, exceptions, multiple
inheritance et al. but when I say to them to just not use the features
they don't understand that usually ends the discussion pretty fast.

Philippe Nobili wrote:

> Hi everybody,
>
> I understand the 'resource  acquisition is initialization' technique
> auto_ptr<> template class supports. However, in its actual definition, I
> find the class rather hazardous to use -- except in very simple cases --
> since it gives you the impression your pointers are safe when they are
> not.
>
> C* c = new C() ;
> auto_ptr<C> pC(c) ;
> {
>  auto_ptr<C> pC2 = pC ;
> }
> ....
>
> Here, ownership is transfered to 'pC2', which is deleted -- and its C
> instance with it -- at the end of its scope. We end up with 'pC' owning
> a dangling pointer.
>
> Although this peace of code is very simple, you can easily imagine
> situations where this may happen. This is even worse than working with
> raw pointers because unexperienced -- and even experienced --
> programmers won't even notice something is wrong with their code at
> first glance.
>
> Is it desirable to have as part of the standard a class that is to
> easily misused ?
>
> Very often, the problem with 'resources' is that they have to be shared
> by many and deleted **only** when not referenced by anybody. In this
> sense auto_ptr<> is of little interest to store a member which is a
> pointer to a class, since you usually use member pointers to share
> something with others (not always though).
---
[ 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                             ]

Hi everybody,

I understand the 'resource  acquisition is initialization' technique
auto_ptr<> template class supports. However, in its actual definition, I
find the class rather hazardous to use -- except in very simple cases --
since it gives you the impression your pointers are safe when they are
not.

C* c = new C() ;
auto_ptr<C> pC(c) ;
{
 auto_ptr<C> pC2 = pC ;
}
....

Here, ownership is transfered to 'pC2', which is deleted -- and its C
instance with it -- at the end of its scope. We end up with 'pC' owning
a dangling pointer.

Although this peace of code is very simple, you can easily imagine
situations where this may happen. This is even worse than working with
raw pointers because unexperienced -- and even experienced --
programmers won't even notice something is wrong with their code at
first glance.

Is it desirable to have as part of the standard a class that is to
easily misused ?

Very often, the problem with 'resources' is that they have to be shared
by many and deleted **only** when not referenced by anybody. In this
sense auto_ptr<> is of little interest to store a member which is a
pointer to a class, since you usually use member pointers to share
something with others (not always though).

Your remarks are most welcome,
                              Philippe.



[ 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                             ]