Re: [boost] Re: Re: shared_ptr comparison

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-21 18:01:29

Kevlin Henney wrote:
> 
> >   From: John Max Skaller <skaller_at_[hidden]>
> >> This seems to be a better idea in theory than in practice:
> >
> >       There is no such thing. Theory is Always Right,
> >Practice is RArely Good. TARPRAG principle. (TM) Max, 19XX, 20XX:-)
> 
> Alas, this assertion has been empirically demonstrated to be false ;-)
>
        Ah, but it has been proven right in theory :-)

> >       Exactly. Which is why the specialisation is a seriously
> >bad idea: this usage is unsafe and can't be generalised.
> 
> You've lost me. If I am dealing with a pointer that represents an array
> I want to have array operations available to be me, 

        No you don't. You want to be fired. :-)

> Why? WADR, I think you may have missed the entire point of the
> discussion. We are talking categorically about C arrays, and not
> contains or random access iterators. 

        Yes. I have't missed the point. I said it clearly, I thought:

        DONT USE C ARRAYS. DO NOT PROVIDE ANY SUPPORT FOR THEM.
THEY'RE BROKEN. THEY DESTROY THE C++ TYPE SYSTEM.

        Is that clear? I'm saying 

        REMOVE ALL LIBRARY SUPPORT. Remove 'smart_array'.
        NO NEW SUPPORT. Do not provide smart_ptr<T[]> specialisation.

        You're talking about changing the 'name' of some
functionality. I'm saying to remove it. In theory -- and therefore
in practice <g>, there is no way to distinguish 'pointer to array
element' from 'pointer to single object'. So it is useless to provide

        smart_array<T> p = new T[n];

because it has to accept a POINTER argument, and so 

        smart_ptr<T> p = new T[n];

will also work, and worse:

        smart_array<T> p = new T;

will work too. Template support simply encourages usage that
the type system cannot determine the correctness of. Templates
are strongly dependent on type, and so the only good solution
is not to provide any support for C arrays at all, and to tell
people not to use them.

        That argument CANNOT be put at the moment, because
there is no library component which allows one to allocate
an array in an object or on the stack (vector uses the heap).
The solution is to provide one -- not provide more template support
for the very feature which makes the type system (on which
templates so strongly depend) unsound.

> It is clear that the overgeneralisation you are seeking is not
> appropriate, and it is also clear that C arrays are less than perfect.
> Trying to generalise imperfection is not helpful, which is why the
> discussion is so specific: it is about pointers and C arrays. That is
> the scope of the problem, period.

        And my answer is: discourage their use by refusing
to provide any template library support.

        The core language _must_ support C arrays for 
compatibility. But they have one use only in a library:
as the only way to implement a first class array type,
which should be used everywhere else. Therefore,
C arrays need no support in the library at all,
and they only need to be used _once_ to implement
a library component (namely, to implement the equivalent
first class array types).

-- 
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