Subject RE: [IB-Architect] Libraries and C++
Author David Schnepper
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.


> -----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:
> Your use of Yahoo! Groups is subject to