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

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2002-01-08 10:51:17

Andrei Alexandrescu wrote:
> Let me repeat this:
> 
> SmartPtr does support arrays.

Not in the sense how boost::scoped_array and boost::shared_array support
them.

> There's /no/ need whatsoever to define a new class ArraySmartPtr. What
> SmartPtr consciously decided not to support, as thoroughly 
> explained on page 183 of MC++D, is the indexing operator 
> and pointer arithmetic. What's next?
> Iterators inside a SmartPtr to array? 

There is no need to exaggerate here. Subscripting is an essential part of
the current interface of the boost array pointers (which, by the way, have a
much lager user base than Loki::SmartPtr), and any generative library that
is claimed to be able to replace the need for hand-crafted smart pointers
should be able to provide that part of the interface. That's what Beman is
trying to do.

> It can go forever.
> 
> Supporting full-fledged arrays and pointer arithmetic could 
> be done in one of two ways:
> 
> 1) Add a new policy.
> 2) Implement it in a StoragePolicy that might wrap another 
> Storage policy.
> 
> Both options are accessible to the existing design. I chose 
> to not use an extra policy. Smart pointers to arrays are sometimes 
> needed, but when they are, you don't really want full-blown array 
> with iteration and bounds checking and whatnot. You want a 
> buffer 

Right! Something that can be a drop-in replacement for char* buf = new
char[n], with all the benefits of automated resource management.

> and you're better off with simply calling 
> GetImpl(sp)[index] to index into the array. 

Huh? So, basically, you are saying that when one replace a pair

    char* buf = new char[n];
    ...
    delete[] buf;

with
    LokiScopedArray<char>::type buf(new char[n]);

she should also went through all the lines in between and replace buf[i] to
GetImpl(buf)[i], just because you decided that having an array notation is
an unnecessary luxury? I would say that such attitude is unlikely to attract
too many users for your library.

> I think this is acceptable. Do you agree?

I don't.

> SmartPtr supports all the Boost smart pointers. 

I believe that's what we are trying to confirm. So far there've been some
issues, like the above.

Aleksey