Re: Re: Re: shared_ptr comparison

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-08-22 05:46:35

>   From: John Max Skaller <skaller_at_[hidden]>
>Subject: Re: Re: Re: shared_ptr comparison
>
>Kevlin Henney wrote:
[...]
>> 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.

No, I was right: you have missed the point :->

I think you may have to restyle your approach to be more realistic.
"Avoid C-style arrays" is a common recommendation and certainly one that
I and others recommend for the common case. However, not all cases are
common. Modern C++ is built on classic C++ and C, and the same is true
for much software. This means that you have to face up to the use of
plain new[] -- denial and fugue will not make the world a better place.

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.

In theory this problem does not exist, but in practice it does. However,
if the theory is right, and therefore the problem does not exist, we
shouldn't have to worry about the practice ;-)

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________