> 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