RE: breaking compatibility

["Stephen M. Webb" <stephen at bregmasoft dot com>]

> From Loren Osborn:
>
> The biggest concern here is that the project still has to build in Visual
> Studio (MS Visual C++) :( ... Visual still uses pretty separate
> *.h headers
> from the new extentionless headers... and they don't mix well...
> we have, in
> the past, tried switching to the new ISO extensionless headers, but we
> encountered some real problems... Unfortuantely the Linux/gcc port is a
> splinter effort, and has to cow-tow to the will of the larger
> Windows/Visual
> C++ code-base... If you can think of a way to get this working with visual
> *AND* gcc without requiring us to change several thousand lines
> of code this
> would be best for us...

I've written a lot of production code that compiles under both the MSVC++
and C++ languages,
specifically MSVC++ 6.0 with all the latest patches and GCC 2.95.2 with the
last release
of libstdc++ it would work with (as well as the CVS version up to early last
month).

The catch is that you can only use the subset of the MSVC++ language that is
in common with
the C++ language.  There is no <istream.h> in the C++ language, but MSVC++
does have a working
<iosfwd>.  GCC supports only the C++ language, not the MSVC++ language.

If you're trying to trick the compiler into doing something subtle like
using a macro to redefine
behaviour of standard functions, you're probably just going to run into
trouble.
The C++ language (and the MSVC++ language) provides a number of ways to
redefine the behaviour
of "new", and purposely tries to make using macros a bad thing.


Stephen M. Webb