slices ; Stroustrup & libstdc++

[Gabriel Dos Reis]

Nathan Myers <ncm@cantrip.org> writes:

| On Mon, Jun 19, 2000 at 06:05:39PM +0200, Gabriel Dos Reis wrote:
| > Gerhard Wesp <gwesp@cosy.sbg.ac.at> writes:
| > | > mentioned that the valarray classes, "were not designed very well.
| > | > In fact, nobody tried to determine whether the final specification
| > | > worked."
| > | 
| > |   indeed i'm starting to get this impression.
| > 
| > I submited a defect, a long time ago. It was considered NAD and
| > classified as a request for extension -- what I think it is not.  If
| > you feel that it is indeed a defect then I'll encourage you to send a
| > note to the committee. You'll have my support.
| 
| You should know, before you start preparing a defect report -- and 
| (one would hope!) doing the huge amount of work necessary to correct it
| properly -- that the Library Working Group considers valarray<> to be
| more or less a failed experiment,

Yes, I have guessed from several attempts that the LWG isn't really
willing to repair some obvious mistakes in valarray's specification --
even though I got support from Bjarne, Nico Josuttis (and Howard, I think).
That isn't, IMHO, a comfortable attitude. 

| ... and is disinclined to add complexity
| to something they would rather deprecate.

However, changing

  T valarray<T>::operator[](int) const

to 

 const T& valarray<T>::operator[](int) const

isn't adding any complexity at all. Nor is adding the assigment
operators to the various *_array helper classes. Actually, the
committee is putting the unnecessary complexities on the shoulders of
the users.

Most of the suggestion I made weren't addition of complexity -- I made
sure they were implementable as opposed to the original specification.

I hope we'll discuss these issues at the next meeting in Toronto.

-- Gaby