> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Domingo 26 de Noviembre de 2000 12:15
>
> I think the order of battle would be this:
>
> 1. Change all engine .c files to .cpp files
> 2. Clean up the million warnings
> 3. Upgrade (i.e. replace) current exception handling
> 4. Gradually convert major subsystems to objects.
>
> I suspect that the first three phases would take under a week.
> A little experimentation will suffice.

That's an optimistic Wolf. About 1, changing extension of files to be
recognized by the compiler as C++ won't be so slow. <g> The only problem is
that AFAIK not all compilers use CPP as the extension, hope they are
configurable. About 2, probably several problems will be caught immediately
by the C++ compiler and the code changed easily but I expect that some of
the warnings require thought. We want to eliminate the cause of the warning,
not the warning itself. About 3, I'm surprised you think setjump/longjump
can be replaced quickly by try/throw/catch... maybe I need experience with
this task to have a decent estimation. About 4... better don't give an
opinion.

> I have great deal of experience with a, er, content store written in
> C++ using gcc on Linux and MSVC++ 6 on NT. No sweat. I have it
> on good authority that the jerk who initially hacked together,
> ah, Firebird had a very similar mindset and coding style. So
> I would say yes, you can expect non-ultra-tricky code to work just
> about everywhere that gcc has already been.

Hmmm, it seems you welcome the idea of gcc on UNIX and MSVC for Windoze.
I've read in some forums that MSVC beats gcc on optimized code, any comment
on this?

> Having experienced
> DEC's original C, I avoid ultra-tricky code with the zeal that I
> use to avoid Dale.
>
> Jim Starkey

Are you willing to come to the level of templates if necessary? What do you
think about trying to replace some preprocessor macros (the ones whose
conversion makes sense) to C++ inline functions?

C.