Re: [boost] shared_ptr comparison

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-18 16:55:37

Howard Hinnant wrote:

> One of the possibilities I would like to see explored is merging
> shared_ptr and shared_array under the same name using a specialization
> on array types.  

        I advise extreme caution. In general, array and pointer
syntax semantics are related in weird enough ways to suggest that this
might not be a good idea.

That is instead of:
> 
> shared_ptr<int>   p1(new int);
> shared_array<int> p2(new int[3]);
> 
> rather this:
> 
> shared_ptr<int>   p1(new int);
> shared_ptr<int[]> p2(new int[3]);
> 
> This is purely a naming issue.  I don't see any issues regarding generic
> programming or the like.

        I do. First, this is NOT a specialisation in the
abstract sense of the word. A pointer to array is a random
access iterator, a pointer to an object is not. Indeed,
it is more likely the other way around: a pointer is a specialisation
of a pointer to array, since it has the much same semantics as a pointer
to a single element array. However, pointers to objects also support
polymorphism, pointers to arrays can only be polymorphic in length
not object type. Construction details differ. So probably, neither
is a special case of the other. :-)

        There are a whole host of differences between single objects
and arrays. So I'd advise extreme caution with specialisations.
In general, all specialisations are WRONG. That's because
they defeat parametric polymorphism. The exception is when a
particular type admits a more efficient implementation than
a general algorithm: that is, when the specialisation is
entirely an optimisation, with no semantic consequences.

[Most FP languages support specialisations ONLY in the compiler
back end, because anything else is likely to be wrong.]

        Because C arrays are broken, one might want to
consider 'array as object'. In this case, there might
be an argument for a specialisation. However the signature

        shared_array<int> 

is in error. The correct signature is

        shared_array<int,3>

since the length is an intrinsic part of the array type.

        In my opinion, the correct way to manage arrays
is to make them first class type by using a template:

        array<int,3>

and then you just use

        shared_pointer< array<int,3> >

Such arrays are especially interesting because the template
class used to implement them can provide #NDEBUG style
conditional compilation which allows array bounds checking
for indexed access, and even provide 'smart' iterators that
also check for illegal operations.

Summary: don't fix shared_pointer. Use array<T,n> instead.
This is well principled. The specialisation is not.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net