> The solution is to add a case for regular assignment (in the
> forementioned section of the standard) to have the expected "splatter"
> semantics.  Generalizing the assignment algorithm could be a slight
> pessimization when the source and destination arrays are already the
> same size.  We could provide a special "assign" method if re-adding the
> optimization is that important.

IMHO, the valarray are not really meant to be resizable; the only
member function that resizes is "resize". To splatter a valarray
during assignment, you would have to

1. Reallocate memory if the size becomes bigger.
2. Keep a separate capacity if the size becomes smaller.
3. Doing the usual if the size is the same.

Then add code to determine which of the above. This would slow things
down somewhat, and eventually begin to sound like a std::vector.

A couple of proposals:

1. Have a refarray class that can wrap an arbitrary sequence into a
valarray-like type. (I'm implementing something similar in my macstl.)

2. Merge all of the functionality of std::valarray into std::vector,
or at least the operators and the subsetting stuff.

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

[To the moderators: I tried sending this via a direct post to the
newsgroup, but nothing showed up, not even a rejection e-mail from you
guys.  Hopefully, you can post it for me.]

The standard says (section 26.3.2.2) that regular assignment for
std::valarray<> is only defined if the source object has the same
number of elements as the destination array.  This optimization
disallows valarrays from being used in the standard containers, or
anything like them, because valarrays don't have the assumed "splatter
the old state without any influence from that old state" semantics that
the containers need.  Other types that could need numerically-optimized
containers, like matrices, but want the usual "splatter" semantics
would have to write special assignment operators if they try to use
valarrays.

You could fake a general assignment by using the "resize" method on the
source and then copying.  Strangely, the description of assignment for
the valarray-subsection types does not mention the restriction, so
using a 100%-subsection of the destination array could work.  The point
is the implicit method, which all non-specialized code uses, doesn't
work.

The solution is to add a case for regular assignment (in the
forementioned section of the standard) to have the expected "splatter"
semantics.  Generalizing the assignment algorithm could be a slight
pessimization when the source and destination arrays are already the
same size.  We could provide a special "assign" method if re-adding the
optimization is that important.

The combo-assignment operators will not get this treatment, since they
require the destination object's previous state.

Could we get this in for TR2?  (Or TR1 if it's not too late.)

Daryle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dwalker07@snet.net (Daryle Walker) wrote in message news:<8AF98806-D533-11D7-A3D6-0003939C8002@snet.net>...
...
> The standard says (section 26.3.2.2) that regular assignment for
> std::valarray<> is only defined if the source object has the same
> number of elements as the destination array. ...

That's not a very clear summary of 26.3.2.2. What is says that the
behavior is not defined. The copy assignment operator itself is
defined, but is allowed to misbehave if that restriction is not
honored.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]