I didn't get the answer in the faq of this group.
Could somebody give me a pointer to an ftp site
where to get an implementation of STL.

[Moderator's reply: here's a couple of new entries for the FAQ list.

Q.  Where can I get a free implementation of STL?
A.  The original HP implementation is available from the following ftp sites:

 ftp://butler.hpl.hp.com/stl
 ftp://ftp.cs.rpi.edu/pub/stl

    Also, versions 2.7 and later of libg++ (the GNU C++ library)
    include a version of STL that works with GNU C++.

Q.  Where can I find more information about STL?
A.  See <http://www.cs.rpi.edu/~musser/stl.html>.

If anyone has any more information to add to this, please post it.
-fjh.]

Thanks

jlm
--
+----------------------------+------------------------------------+
|   Jean-Louis Moser         |    2001 SA                         |
|   tel: 33 (1)46.66.54.54   |    2, rue de la renaissance        |
|   Email: jlm@two-oo-one.fr |    F-92184 Antony Cedex            |
+----------------------------+------------------------------------+
---
[ 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. ]

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. ]

>>>>> "MA" == Matt Austern <matt@godzilla.EECS.Berkeley.EDU> writes:
[...]
MA> Which reminds me: I've heard rumors that there are known problems with
MA> the current definition of valarrays, that they don't actually solve
MA> the aliasing problems that they were supposed to.  I know no details.
MA> Has anyone else heard anything of this sort, and, if so, can you
MA> provide any specific information?
[...]
Hmm, here is a summary of what I have seen.

During the public comment period (here in the US) I submitted a comment
and proposal arguing that any valarray implementation in C++ conforming to the
current DWP text (and not relying on specific compiler support) would
be very innefficient. The alternative I proposed was based on experience
with implementing portable but efficient numerical arrays; my original
proposal can be found in
 ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray/Documents/ansirev.*
Implementations close to that proposalcan also be found there.
This proposal introduces the concept of `storage model' to relax the
type-requirements of valarray operators, e.g.:
 valarray<double> a(1000), b(1000);
 a+b; // Result is not necessarily of type valarray<double>;
      // could be e.g. of type valarray<double, ArraySum<double> >.
Hence the new template is declared as:
 template<class T, class M = c_array> class valarray;
I also proposed a standard m_array model that would allow storage of
numbers outside the C address-space (e.g., for distributed computing
purposes). Note that the storage model was not intended to be
substitutable by user-defined classes.

My proposal was cross-checked by someone else who came up with another
idea: make valarray and interface class template to STL containers
(a ``container adaptor'').

E.g. valarray<double, vector<double> > a(1000);

This leads to a very elegant connection with the rest of the libraries,
but IMO reintroduces constraints that lead to inefficiencies.

Given the reluctance to make any major change to the draft at this
stage, it is unclear (to me) whether any significant improvement will
be accepted (or even put up for a vote).

Note that neither proposal addresses aliasing better than the DWP; the
exploitation of non-aliasing will require special compiler support
(unless, say, the `restrict' keyword becomes standard).  OTOH, at
least one person has hinted that the current DWP text is not
sufficient to allow aggressive optimization (I understand this person
writes high-performance compilers).
Two examples:
a) Generalized slices can be degenerate in the sense that:
 a[gslice(start, lengths, strides)]
   can contain an element of `a' more than once (apparently
   this hinders optimization),

b) void f(valarray<double>& a, valarray<double>& b);
   Unlike in Fortran, a and b are not guaranteed different.

 Daveed
---
[ 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. ]