Re: [boost] Re: Re: Re: shared_ptr comparison

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-22 12:27:14

Kevlin Henney wrote:

> The idea that you can stop people using C-style arrays, whether their
> uses are well informed or not, by just banning abstractions built around
> them is wonderful in theory. Of course, we know that in practice it
> fails miserably, because human beings do not work like that -- to
> pretend they do is at best unhelpful. We know for a fact that the
> absence of library support for something like auto_array simply results
> in FAQs and wheel reinvention.

        I will not dispute this. My contention is that the correct
solution is to provide a first class array type. There really
IS a genuine need here: an omission from the Standard.
People keep reinventing the wheel, because there is a lack of
functionality. My contention is that we CAN and SHOULD provide
the missing functionality. But the technical way to do it is NOT
to provide support for C arrays, by a direct replacement for them.

        Doing so means the answer is: "replace that C array
with array<T>, and use smart_ptr< array<T> >", rather than
"use array_ptr<T>" no matter what it is named. 
At least one reason is that the array<T> solution is sounder
and much more general: it fixes a lot of problems, not just
a particular one. For example, what about (uggh): auto_ptr?
What about a plain old vector of arrays? You truly don't
want 'array_vector<T>' and or its semantic equivalent
named 'vector<T[]>' which is specialised: you'd have to
specialise almost the whole Standard (and all user) libraries.
But using a first class array _generates_ all the specialisations
correctly by combination: it fits properly into the type system.

        In other words: problems with C arrays won't just
go away, but the kind of approach your advocating will not
solve the problem, only exacerbate it: replacing
the C array with an array<T> solves the problem once
and for all. [At least, thats the idea -- we'd need to
look at an actual implementation to be sure]
 
-- 
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