🚀 go-pugleaf

matt@godzilla.EECS.Berkeley.EDU (Matt Austern) wrote:
>In article <VANDEVOD.95Oct11203807@avs.cs.rpi.edu> vandevod@cs.rpi.edu (David Vandevoorde) writes:
>
>> Vaguely related:
>> 
>> Q. Is there a free implementation available of the valarray templates?
>> A. Not that I (we?) know of, but approximate implementations are
>>    available from:
>> 	ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray
>>    Non-commercial use is free.
>
>Which reminds me: I've heard rumors that there are known problems with
>the current definition of valarrays, that they don't actually solve
>the aliasing problems that they were supposed to.  I know no details.
>Has anyone else heard anything of this sort, and, if so, can you
>provide any specific information?
>
>If this is true, of course, then we can expect the final form of
>valarrays to differ from what we've seen in the draft standard.

There are a couple of proposals to change valarray floating
around at present: an extension to support a parameter 
controlling allocation category, and a proposal to replace
valarray with an STL container adaptor. Possibly these will
end up combined, and possibly it is too late in the standards
process for anything to change at all.

AFIK the existing valarray has appropriate constraints to
allow optimisations based on no aliasing, however there is
some concern that naive implementations will create
unnecessary copies of things.


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]