> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Sábado 25 de Noviembre de 2000 12:56

[snip]

> A very elegant solution is available in C++: Each controlled
> object contains a synchronization object which is controlled
> through a stack local object with a destructor to release the
> lock on function exit or exception unwind. A C implementation
> is possible, but without object destructors, it would involve
> a great deal of hard to test, hard to maintain, fussy code,
> with great temptation for a developer to think "ah, I know
> nothing I am calling can ever throw an exception, so why
> don't I just skip the cleanup."

Apart from setjump/longjump, what made me to abandon C in favor of C++ is
not only better type checking (maybe a thing that a db engine doesn't need
or doesn't want by nature) but that C code is plagued by ugly preprocessor
macros. For what I've seen through the SF's web interface to the Firebird
CVS, IB code is not an exception. While some preprocessor macros are
unreplaceable directly, others can be exchanged for C++ inline functions.

> If there is ambition to move FireBird forward, I think a conversion
> to C++ is not only desirable, but essential. Or to put the
> question another way, I think the effort to convert to C++
> will return a major short term profit and a promise of long
> term dividends ("dividends" -- an amusing but archaic financial
> concept).

Oh, an OOW (Object Oriented Wolf)
<g>
Do you think that all the code needs to be rethinked or only retouched in
the critical places?
What's the state of C++ compilers in the N+1 platforms today? Can we rely on
non-ultra-tricky code behaving the same on several compilers?

C.