🚀 go-pugleaf

In article <KANZE.95Aug10105751@slsvhdt.lts.sel.alcatel.de> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
In article <40c8ot$q00@metro.ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au
(John Max Skaller) writes:

|> In article <1995Aug4.165955@opal.tufts.edu>,
|> Jonathan Borden <jkauer@opal.tufts.edu> wrote:
|> >In article <3vo8a7$jde@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
|> >> 	valarray isn't an STL container because its purpose is
|> >> quite different. Here's my picture:

The purpose last time I heard any comment about valarray was to define
a type which could benefit from optimizations of knowing that it does
not have pointers pointing to various places etc.  I don't know the
full story here, except that it seems that fortran has a similiar
capability and it out optimzes C.

From the definition of valarray it sounds like this could all be done
in parrallel.  There may be others optimzations possible as well.

valarray are not containers but matrices.??
nah that doesn't help.

|> 	A vector is a sequence, obviously. So is a list.
|> 	The very notion of iteration is inherently a question of
|> enumerating things: linearity.

I would disagree, at least for the meaning we normally give to
`iterator' in this context.  An iterator does not formally impose an
ordering.  In particular, in my implementation of SetOf (which uses
open hashing), if an element is inserted while an iterator is active,
it is undefined whether the element will be considered before or after
the iterator.

If you iterate through things you have created an order.
The order in which you went through the set.
This does not make the set itself have order only the access.

It is also true that the STL is a little weird about sets, etc.

Just a few thoughts,
Eric
---
[ 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. ]