Re: Re: shared_ptr comparison

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-08-21 02:24:43

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

>>         shared_ptr< array<T> > p;
>>         ...
>>         (*p)[i] = ...;
>> 
>> Whereas a shared (or scoped) array that was specialised as such would
>> support operator[] directly. 
>
>       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, and if am not I want
to have them suppressed. This is why either a specialisation (eg
shared_ptr<T[]>) or a named variant (shared_array) is a good idea. The
example above demonstrates quite clearly why your proposal does not meet
expectations.

>> So, dropping the idea of a separate shared array implementation is not
>> really appropriate. It becomes a question of whether to support it as a
>> specialisation or as a separately named class template.
>
>       No. You aren't being logical. The correct conclusion
>is that shared pointers denote containers, of which array<T>
>is just one example. 

I think your school of logic is not on the same block or even campus as
mine ;-)

>If you used a vector:
>
>       shared_ptr<vector<T>> x;
>       x[i] // error!!
>
>you'd EXPECT an error.  So you should EXPECT an error
>for an array container too -- after all a vector is a
>kind of array.
>
>If you REALLY want a 'specialisation', it should work for
>ALL containers with a canonical random access iterator.

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. We are not talking about whether C
or C++ is broken and how to fix them -- although such a discussion is
interesting, it is not actually helpful in this case.

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.

Kevlin
____________________________________________________________

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