|Subject||RE: [IB-Architect] Rock>Java>Threads>Hardplace|
|Author||Claudio Valderrama C.|
> -----Original Message-----That's an optimistic Wolf. About 1, changing extension of files to be
> 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.
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
> I have great deal of experience with a, er, content store written inHmmm, it seems you welcome the idea of gcc on UNIX and MSVC for Windoze.
> 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.
I've read in some forums that MSVC beats gcc on optimized code, any comment
> Having experiencedAre you willing to come to the level of templates if necessary? What do you
> DEC's original C, I avoid ultra-tricky code with the zeal that I
> use to avoid Dale.
> Jim Starkey
think about trying to replace some preprocessor macros (the ones whose
conversion makes sense) to C++ inline functions?