Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-04 16:04:47

> Regardless of the exact technique used, I don't see how we can use the
Loki
> SmartPtr as the base (or typedef template when that becomes available) for
> the Boost smart pointers without doing something to increase inter-policy
> communication.

I think inter-policy communication would be good, but there are two points
I'd like to make. One is that supporting arrays is the wrong aim to shoot
for. The second is that the mechanism with independent policies has proven
very flexible so far, and that alternate mechanisms need to bring a lot of
bang to justify their added complexity. Let me detail my points below.

Support for arrays already exists in SmartPtr to a certain extent. You can
easily write a policy that implements Destroy() by calling delete[]. Then,
you can index into the array by calling GetImpl(sp). For example:

SomeSmartArrayPtr sp;
...
GetImpl(sp)[5] = 0;

The obvious objection is that true support for arrays means providing an
indexing operator. Actually an earlier SmartPtr implementation did support
that, but in the end I decided to drop it.

The problem is that smart pointers seldom point to arrays, and when they do,
you use them only as back-end in a more elaborate data structure (such as a
full-fledged array itself) rather than a prima donna array. (How did that
line sound? Ah, "If you want arrays, use std::vector.") When you think of
implementing indexing for a smart pointer, checking index boundaries
immediately comes to mind and before you know it, you are talking about
implementation of full-blown arrays!

That's why I decided to leave in only Spartan array support, without support
for indexing. The bad thing with "nice-to-have" features is that the list
can go on and on and on. You have to define your design's boundaries. Smart
pointers are not arrays. If one wants arrays, she can implement an array
using SmartPtr as a building block. I think this is only fair and
reasonable.

My second point was that a design with orthogonal policies is simplest and
should be strived for. If SmartPtr needs interacting policies, there has to
be a strong practical argument in favor of that. Until now, the current
design of SmartPtr has proven considerably flexible - there's no smart
pointer implementation that me or other users needed that couldn't be
implemented within the existing framework.

I recall you once said SmartPtr is too complicated. Now it seems it's too
simple. Guess that's a good sign :o).

Andrei