I, also, have had poor experiences with using STL in
client/server work. (I agree, however, that STLport seems
to be the best of the lot).

In particular, what bugged me about the STL was I never
could understand when it would choose to alloc/free memory.
Since this was vital to my application, AND I couldn't
get a version of STL to work in all of the 3 environments I
cared about, I took a pass on everything in it.

Dave

> -----Original Message-----
> From: Geoff Worboys [mailto:geoff@...]
> Sent: Sunday, October 13, 2002 5:37 PM
> To: Ann W. Harrison
> Subject: Re: [IB-Architect] Libraries and C++
>
>
> > Given that Firebird makes relatively little use of anything
> > that's been added to operating systems since the early 1980's,
> > do we really need those libraries or can we reproduce the bits
> > that are necessary and eliminate lots of porting / C++ version
> > problems?
>
> > I seriously want to know -
>
> I've only just come back to C++ after a long spell with Pascal.
>
> When I used to program with C++ a few years ago I had quite
> similar opinions of the STL as your expressive counterpart.
>
> These days the STL seems to have improved considerably, both in
> its portability and its reliability and consistency. I am now
> involved in writing a couple of libraries (one of them for
> accessing FB) and have chosen to use the STL. I still have some
> portability issues, but nothing too difficult to work around.
>
> That is not to say that I am necessarily a fan of everything
> in the STL, or the way the STL does every little thing. BUT it
> is a standard (of sorts) and it can help to clean up code and
> make it easier for other developers to come into a code base.
>
> However, my opinion of the STL for client based libraries and
> applications does not necessarily translate to something like
> Firebird. There are still STL string (and other container)
> template implementations that are not thread-safe, or if made
> thread-safe do not perform well. I also see similar potential
> problems with various "smart" pointer templates from related
> libraries.
>
> You probably could use an STL implementation, provided you could
> choose _one_ that is both portable and compatible with Firebird.
> That way you only need be concerned about compiler portability
> and not differences in STL from compiler to compiler.
>
> For example; STLport seems very portable. Its string
> implementation does not use reference counting or COW so (AFAIK)
> it can be used effectively in a multithreaded environment.
>
> OTOH, for maximum efficiency and performance I would suggest
> that many aspects of the Firebird code would benefit from their
> own class/template implementations anyway (perhaps that has
> already happened in FB1.5, I have not looked).
>
> I imagine that you may choose not to use STL directly on
> interface parts of the various classes and code. But that need
> not stop code from using STL for internal manipulations and
> still gain significant benefit.
>
>
> Just some thoughts.
>
> --
> Geoff Worboys
> Telesis Computing
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>