Re: [Mingw-users] math.h - defining M_PI and other constants?

[Tor L. <tm...@ik...>]

Oscar Fuentes writes:
 > Why is MSVC compatibility so important?

If you maintain some Open Source library, do you want to restrict the
people being able to compile it to gcc users? Wouldn't that be as
narrowminded as writing Open Source code for MSVC users only?

The higher the compatibility between mingw and MSVC is, the less
#ifdefs needed in such a library. The better the chance that code
distributed in source form, even if developed by a mingw user, is
useful also to MSVC users. Wouldn't that only be good PR for mingw?

I can't afford MSVC at home, and I strongly support Open Source, but
that doesn't mean that I would pretend that gcc is faster than MSVC or
think that people who prefer it to gcc should be ignored. (If I could
afford it, I would probably use Intel's compiler.)

After all, mingw and MSVC use the same C library, so it makes sense
that the headers (which, after all, are supposed to describe the API
of said library) are compatible, doesn't it?

 > Borland and Cygwin gcc's define M_PI and other constants. Are those
 > constants mandated by the C standard?

No. They are just very common. Presumably they are mentioned in some
X/Open or similar standard. I certainly agree that Microsoft was silly
in not including them, but that's a moot point now.

 > Anyways, how could hurt to MSVC compatibility the fact of having
 > those constants? Are people here afraid of developing code
 > unportable to MS?

See above. If mingw has lots of stuff in the headers, or in its
libmingw32 library, that MSVC hasn't, code developer using mingw is
harder to compile with MSVC. Isn't that bad PR?

What would you think if you found this nice code snippet on the net,
but notice that it contains silly (and unnecessary) MSVCisms and is
hard to port to gcc?  Shouldn't we, the Open Source people, be more
openminded and accept that all the world isn't using our compiler?

--tml