[boost] Re: Loki::SmartPtr (boostified) use as shared resource

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-29 19:00:03

"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
news:000801c1ef10$5ca22550$239487d9_at_TimeMachine...
> I think this has been brushed under the carpet a lot, but following the
> dialog mostly between Andrei and Gennadiy the issue came up several times
> where the smart_resource aspects of smart_ptr had been overlooked, or
there
> was an awkward naming issue depending on whether we were dealing with
> pointers or general resources.
>
> I am prepared to accept that I am alone in having reservations about using
> smart_ptr to manage non-pointer resources (as opposed to having a discreet
> smart_resource class), and if everyone else is happy with this I will
bring
> it up no more. However, nobody has, AFAICS explicity said this yet.
>
> FWIW, my view of a separate smart_resource does not preclude the sharing
of
> individual existing smart_ptr _policies_, where appropriate.

Let me tell you everything that happened, and that might shed some light on
how Loki::SmartPtr came about, what my view onm the issue is, and what I
believe can be done henceforth.

When I was writing about smart pointers in MC++D, I tried many, many
designs. In particular, I tried and dismissed some designs that have been
vehiculated later here and on comp.lang.c++.moderated. (This has had the
annoying effect of seeming dishonesty on my part; when someone suggests a
design, I tend to reply with "I tried and rejected that", which is just too
snooty.)

In particular, I tried a very interesting design based on integer
arithmetic, which would allow to customize behaviour in some 32 ways, as
many bits are in an integer. I decided to drop that design because it did
not allow comfortable user-defined behaviour.

After trying all those designs and settled on policies, I realized that the
SmartPtr defined as such was remarkably flexible. It was so flexible, that
actually it was a "smart resource" all right! So I considered changing the
whole chapter into a discussion on "smart resources", not "smart pointers".

That was quite a change, which prompted me to write email to a good friend
of mine, who's also a prominent C++ guru. He dismissed the whole idea in
categoric terms and advised me against transforming the chapter on smart
pointers into one on smart resources. There were two reasons. One was that
my writing lacked unity - it started discussing "smart pointers" then went
on to "smart resources", thus confusing the reader. The second was "brand
dillution": people might be more comfortable with a well-known idiom such a
smart pointer (and discovering that, hey, it could also be a smart resource)
as opposed to learning about smart resources, which, well, in particular can
be pointers.

After that email exchange, I decided two things. One was that the chapter
will discuss smart pointers, and will only hint in passing that the concept
is generalizable to resources that don't have pointer representation. So the
text is very low-key (but not silent) when it comes about non-pointer
resources. The second decision was to have the code fully support
non-pointer resources, and leave the debate about naming for later. That
"later" became "now".

Therefore, my belief is that smart pointers can be quite naturally used as
smart resources, barring a couple of design awkwardnesses on my part.
Whether this is, or it isn't, the way to go, remains to be seen.

Andrei