When I started looking at the tools to use for software development
in which the target OS could be Windows ('95 or NT) or Unix (various
flavors), I picked C++ as the best language to use and STL and the
standard C++ library as things to depend on.

It looks like the choice of STL was premature.  I've incorporated
only a tiny bit of string and vector classes in my code, doing my
initial development with Microsoft's VC++ and their copy of STL.
When I tried to compile under Linux (2.0.29, if that means anything to
anybody) with g++, I found
  a) the compiler explicitly states that most of the functionality
     of namespace is broken,
  b) vector doesn't have a resize method,
  c) include file "string" doesn't exist at all here, and the Linux
     string class bears little resemblance to the Microsoft basic_string.

I get the feeling that I'm asking for portability trouble if I depend
on STL to be predictable from one machine to the next.

Are my test cases inappropriate, or are the waters still pretty muddy
when it comes to STL?
--

Duane Morse e-mail: duane@anasazi.com
(602) 861-7609; Phoenix, Arizona
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Duane Morse <duane@ds9.anasazi.com> wrote:
: When I started looking at the tools to use for software development
: in which the target OS could be Windows ('95 or NT) or Unix (various
: flavors), I picked C++ as the best language to use and STL and the
: standard C++ library as things to depend on.

Good choice :-).

: It looks like the choice of STL was premature.

: ...

: I get the feeling that I'm asking for portability trouble if I depend
: on STL to be predictable from one machine to the next.

: Are my test cases inappropriate, or are the waters still pretty muddy
: when it comes to STL?

It's just that you have to be extra careful with STL.
STL uses many advanced and new features of the language, and
STL was added to the language only 2 years ago. Moreover,
some changes to the language were made specifically
to accommodate STL. Surely, g++ didn't have time
to catch up with all that. Besides, last significant g++
release was about 2 years old - almost before STL.

So I would give several practical advices:

1. stick to the more-or-less portable STL subset.

2. Get newer STL adaptation from Boris Fomichev's site:
   http://www.ipmce.su/people/fbp/stl/stlport.html

3. If the features you need are not supported by g++ wait til 2.8.0
   is released, or buy a good commercial compiler, say from Comeau
   Computing http://http://www.comeaucomputing.com/ or from
   any other vendor supporting Linux.

4. Post specific questions to comp.lang.c++.moderated (this newsgroup
   is inappropriate).

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> Duane Morse <duane@ds9.anasazi.com> writes:

> When I tried to compile under Linux (2.0.29, if that means anything to
> anybody) with g++, I found
>   a) the compiler explicitly states that most of the functionality
>      of namespace is broken,

Yup.  But you don't need namespaces to use STL.

>   b) vector doesn't have a resize method,

The old HP STL doesn't.  You should check out Boris Fomichev's port of SGI
STL to g++ 2.7.2:

  http://www.ipmce.su/people/fbp/stl/stlport.html

>   c) include file "string" doesn't exist at all here, and the Linux
>      string class bears little resemblance to the Microsoft basic_string.

Hmm?  libstdc++ does include <string>, which should look very similar to
Microsoft's.  Perhaps your installation is flawed.  The old libg++ String
class in <String.h> is unrelated and should not be used in new code.

Jason
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

duane@ds9.anasazi.com (Duane Morse) writes:

>  a) the compiler explicitly states that most of the functionality
>     of namespace is broken,

namespaces are slow to catch on. We're doing a very large portable app
on Windows NT and SGI using the STL and don't need/use em.

>  b) vector doesn't have a resize method,

In my version (the SGI version of STL) it does. It's easy to implement
anyway:

    void resize(size_type new_size, const T& x) {
        if (new_size < size())
            erase(begin() + new_size, end());
        else
            insert(end(), new_size - size(), x);
    }


>  c) include file "string" doesn't exist at all here, and the Linux
>     string class bears little resemblance to the Microsoft basic_string.

The current naming "standard" is also slow in catching on. Usually there
is a string class on unix under a different filename (it's mstring.h on
the SGI). Just make a symbolic link to it called "string". Do the same
for "vector" and "list" and etc. for the other STL containers you want
to use.

>I get the feeling that I'm asking for portability trouble if I depend
>on STL to be predictable from one machine to the next.

Currently you've snagged minor compatibility problems with namespaces
and otherwise differing implementations of the STL and file-name
conventions. I hear the latest GCC will be using SGI's implementation
of the STL. Do yourself a favor and download it.

Cheers!

--
Paul Miller                  | paul@elastic.avid.com
SGI Software Engineer        | Opinions expressed here are my own.
     Elastic Reality - a division of Avid Technology, Inc.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

duane@ds9.anasazi.com (Duane Morse) writes:

>When I started looking at the tools to use for software development
>in which the target OS could be Windows ('95 or NT) or Unix (various
>flavors), I picked C++ as the best language to use and STL and the
>standard C++ library as things to depend on.
>
>It looks like the choice of STL was premature.
...
>I get the feeling that I'm asking for portability trouble if I depend
>on STL to be predictable from one machine to the next.

Yep, I'd agree with that.

In fact, I'd say that using templates at all will probably make portability
more difficult.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<5natvt$ij3@mulga.cs.mu.OZ.AU>...
> duane@ds9.anasazi.com (Duane Morse) writes:
>
> >When I started looking at the tools to use for software development
> >in which the target OS could be Windows ('95 or NT) or Unix (various
> >flavors), I picked C++ as the best language to use and STL and the
> >standard C++ library as things to depend on.
> >
> >It looks like the choice of STL was premature.
> ...
> >I get the feeling that I'm asking for portability trouble if I depend
> >on STL to be predictable from one machine to the next.
>
> Yep, I'd agree with that.
>
> In fact, I'd say that using templates at all will probably make
portability
> more difficult.

Not to mention that the current standard does not define an exception-safe
STL, despite that fact the standard C++ memory allocator (which STL of
course uses) is *defined* as throwing an exception upon failure!  That is,
even in the event of a failure *defined* the standard, there is no garantee
that your standard STL data structures will remain valid nor that they
won't leak memory unpredictably.

However, there is an effort underway to remedy this and modify that
standard to include proper exception-safety requirements for the containers
and algorithms in the STL.  There is also an actual exception-safe (and
multi-compiler friendly) adaptation of STL available at
http://www.ipmce.su/people/fbp/stl/effort.html.  Specifically, check out
http://www.ipmce.su/people/fbp/stl/eh_contract.html for a description of
some of the new exception-safe STL theory.


Best regards,
Matt Arnold
Boston, USA :: http://python.ics.uci.edu/~marnold/
C++/MIDI/Win32/95 developer :: e/DM/7R7/RF/C&E/A-Box

Remove "don't.spam." prefix to obtain my valid email address.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

duane@ds9.anasazi.com (Duane Morse) writes:

|>  I get the feeling that I'm asking for portability trouble if I depend
|>  on STL to be predictable from one machine to the next.

You guessed it.  In production code, presently, about the only library
you can count on is a Cfront-like iostream.  (And the C libraries, of
course.)

My current recommendations are to stick with the libraries you have been
using for a while.  (In production code, of course.  You should
definitly be playing around with STL to get a feel for the future.)

If you are not currently using any libraries, then I would recommend
getting a "near standard" library from one of the third party suppliers,
and using it.  No sense in learning something different just to change
later.

|>  Are my test cases inappropriate, or are the waters still pretty muddy
|>  when it comes to STL?

Very.  The version standardized uses language features that are not
often available on current compilers.  IF you want to use STL in
production code, you should not count on the version that comes (or may
come) with your compiler; there is too much variance.  Get a third party
version, after checking how they handle multiple platforms.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>duane@ds9.anasazi.com (Duane Morse) writes:
>
>|>  I get the feeling that I'm asking for portability trouble if I depend
>|>  on STL to be predictable from one machine to the next.
>
>You guessed it.  In production code, presently, about the only library
>you can count on is a Cfront-like iostream.  (And the C libraries, of
>course.)

Just to voice a descenting voice here. IMHO there is a large subset of
STL that you *can* count on. If you get a 3rd party library (like the
SGI freeware one) and use it on all of your compilers, whether they
provide their own STL or not, then you will have a fair amount of
portability. Stick to the most stable features and you should have
little trouble porting to fully-compliant versions when the standard is
complete. The one thing you will probably need to do is use macros to
handle namespaces (e.g. #define USE_VECTOR using std::vector;), in case
some of your compilers don't implement namespaces. The vectors should be
defined as no-ops on compilers that don't have namespaces.

>My current recommendations are to stick with the libraries you have been
>using for a while.  (In production code, of course.  You should
>definitly be playing around with STL to get a feel for the future.)

This depends on which libraries you are currently using and how
entrenched you are. I am working on a project that makes extensive use
of the Rogue Wave library and I can't wait to switch over to STL. RW
doesn't provide mutating iterators (imagine!), const iterators or *fast*
sorted collections (e.g. set and map).  Their implementations of
RWVector and RWCString are very inefficient. They do have a newer
version of their library that remedies some of these problems because it
is built on top of STL, but then you might as well just use STL directly
(except during a transition period). Basically what I am saying is that
there are good reasons to switch to STL *right now*, depending on your
situation.

P.S. My client doesn't use exceptions right now, so an exception-safe
STL is not an issue for us. It would be for someone else *if* they are
already using a library that *is* exception safe (RW seems to at least
make an attempt at exception safety. Some of its limitations seem to
make it easier to do).

>If you are not currently using any libraries, then I would recommend
>getting a "near standard" library from one of the third party suppliers,
>and using it.  No sense in learning something different just to change
>later.

Right.

>|>  Are my test cases inappropriate, or are the waters still pretty muddy
>|>  when it comes to STL?
>
>Very.  The version standardized uses language features that are not
>often available on current compilers.  IF you want to use STL in
>production code, you should not count on the version that comes (or may
>come) with your compiler; there is too much variance.  Get a third party
>version, after checking how they handle multiple platforms.

Here we agree fully. Clearly this is a judgement call. James' points are
quite valid, but I thought you should have the benefit of another point
of view.


-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]