TITLE: smart pointer miscellanea

(Newsgroups: comp.lang.c++.moderated, 25 May 99)


SHIVSHANKS: shivshanks@my-dejanews.com

>>> You may have a look at www.boost.org for an alternative.


STANLEY: stanley@West.Sun.COM (Stanley Friesen)

>> Thanks a lot. They address almost all of the issues I had with
>> auto_ptr<>! And its a shame the Std C++ comittee chose to ignore all
>> these kinds of smart pointers. Anyone knows why?!


STROUSTRUP: Bjarne Stroustrup <bs@research.att.com>

The committee didn't ignore smart pointers; it considered smart pointers
repeatedly and decided to include only the most minimal smart pointer:
auto_ptr.


STANLEY:

> A) They cause more performance and space overhead.


STROUSTRUP:

Some do. Some of us considered a smart pointer type that involved a free
store allocation plus deallocation per pointer unacceptable for general
use.

One problem is that there has been people advocating *exclusive* use of
"safe" pointers of that sort. Rules such as "never use built-in pointers,
always use smart_ptr" can be quite appropriate for a particular project,
but are unsuitable as a general rule for the use of C++. Had a single
"smart pointer" suitable for all uses existed, it would have been voted
in without much discussion. However, no such paragon of virtue existed;
nor could it (IMO) exist.


STANLEY:

> B) Many of these did not *exist* at the time.

STROUSTRUP:

Many did exist. That was one of the problems. Smart pointers seem to
proliferate. Some of that proliferation happens for perfectly good reasons
because there are many different demands on constructs referring to
information. However, the standard couldn't support a dozen smart pointer
types (that would create total confusion).

What the committee considered was variations of "smart pointers" for

 (1) the "resource acquisition is initialization" approach to
     exception safety (which was required by the UK)
 (2) a "counted pointer" that ensured automatic deletion of the
     object pointed to.

In the end, there was consensus on (1) - the auto_ptr - but not on (2).


STANLEY:

> C) Nobody presented a full proposal to the committee in time that
>    addressed all issues.

STROUSTRUP:

Greg Colvin presented several proposals for the two kinds of smart pointers
mentioned above (incl. the auto_ptr that was accepted). However, you are
right that the talk about other kinds of "smart pointers" (such as checked
pointers, pointers to arrays, pointers to persistent information, handles, 
...) was only talk (and code somewhere) rather than formal proposals.

I didn't see anything that could unify the various smart pointers you can
find in libraries today into a single type suitable for standardization.


STANLEY:

> Auto_ptr<> is intended as a *minimalist* smart pointer, one that is
> virtually free to use in terms of time and space.

STROUSTRUP:

Exactly


STANLEY:

> If you need more, just implement it yourself, or use a library.

STROUSTRUP:

"smart pointers" are easy to design and implement when you have a single
purpose and well-known constraints on solutions.