🚀 go-pugleaf

In article <3vo8a7$jde@metro.ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
> In article <3um3id$qf1@offas_dike.sbil.co.uk>,
> Marc Shepherd <shepherd@debussy.sbi.com> wrote:
>>>
>>>>Why is "valarray" not an STL container? (Excuse me if this question
>>>>has already been answered - I was out of net.contact for a while).
>>>
>>>STL already has array classes, if you want an STL-compatible array.
>>>
> 
>>Yes, but many of the interface distinctions between valarray and STL
>>containers are gratuitous--i.e., not a necessary consequence of the
>>'desired semantics' that Steve refers to.  
>>
>>IMHO, the interface of 'valarray' *should* be STL-compatible, except
>>where doing so would interfere with the 'desired semantics'.  I have
>>already submitted an official public comment to this effect.  All classes
>>accepted in the standard, it seems to me, should have a consistent design
>>style and should appear to have flowed from a common thought process.
>>The fact that 'valarray' and 'STL' were designed and proposed by different
>>committee members is irrelevant: at this point, it is just one Standard.
> 
> 	valarray isn't an STL container because its purpose is
> quite different. Here's my picture:
> 
> 	STL is based on the notion that everything can be organised
> into sequences: these sequences are represented by pairs of iterators.
> There are no trees in STL because a tree isn't a linear sequence.

	hmmm... what about maps & sets, the hp implementation (and hence
many derivatives) code these as red-black trees. In STL there are several
types of iterators, a sequential iterator is one type, however, random access
iterators also exist.


> 
> 	Why just sequences? The answer is that that is all that
> a single thread of control can handle. Even conceptually parallel
> processes must be organised into _some_ sequence for a conventional
> computer to use it.
> 

	Since STL in fact supports more than lists and vectors as containers
this answer does not follow. I'm not sure that STL references types of CPU's
at all.

> 	valarray exists exactly because most CPU's support
> SOME kind of parallelism -- whether it be limited to caching,
> emulated by threads and tasks, done by vectorisation, 
> or multiprocessing. To optimise processing for such systems
> requires additional constraints on the software -- valarray
> has been carefully designed to embody some constraints which
> enable this kind of optimisation.
> 
> 	Such parallelism is posible for STL code too -- but
> only if the compiler carefully analyses the code to determine
> if what the programmer coded as a sequence can be done
> non-sequentially without changing the semantics.
> 
> 	With valarray, certain such operations are _guarranteed_
> to be vectorisable: the compiler doesn't need to do any work.
> 
> 	For example adding two valarrays either requires doubling
> one of the arrays (if the two arrays are the same array) or adding
> component by component -- in either case element by element
> operations can be done in parallel. 
> 
> 	Why?: Because valarray is VALUE ORIENTED. A valarray is
> a SINGLE object. Whereas STL is REFERENCE ORIENTED. A pair of
> iterators denotes a method of finding elements IN SEQUENCE.
> 
> 	PS: Yes I know this is an oversimplification.
> 
> 	PS2: Pete Becker argued strenuously that "string" was a single
> object and should NOT be STL'ised. But it has been, and the result
> is undoubtedly a loss of optimisation opportunites in favour of
> a more flexible interface.
> 
	I'm not sure this follows either. Assuming the STL templates are
in-line optimized, the string class is ultimately represented by
a   char*, and a well-designed optimizer shouldn't suffer.

> 	BTW: you may sensibly ask why C++ does not have
> support for non-sequential processing of non-numeric
> information. The answer is: the numerical people AGREE to a large
> extent on what they need. Special hardware has always 
> been built for them.

	there are different types of non-sequential processing of non-numeric
information. several modern os's allow multithreading/multiprocessing,
and there are several object systems which allow distributed processing.
Admittedly, standard C++ doesn't directly support multithreading ---
however ObjectSpace's STL (for one) does provide generic multithreading support
and concurrency management. Similarly Corba type IDL's provide C++ mappings
to iterfaces (i.e. pure virtual base classes) and Microsoft's COM/OLE is
fairly stongly C++ oriented (again pure virtual base classes). Using
holder & envelope objects STL containers are an effective way to deal with
both multithreading and object interfaces.

jon borden
jabr technology corporation
component medical software