Tor Lillqvist <tml@...> writes:
> Jos=E9 Fonseca writes:
> > The key for cross platform is in the _application_ and not on the
> > _compiler_ used. Anyway, if someone had a Open source library which th=
> > want to make it portable across several systems, they would probably
> > target gcc first since it runs on *much* more platforms than MSVC...
> Yes, probably. So what? That doesn't mean that any sensible Open
> Source developer would on purpose sprinkle gcc-only features in his
> code without providing standard compliant alternatives.
A programmer should know their tools. If he use gcc-only features
when he is targeting standard C/C++ the problem resides on his
knowledge, not on the compiler.
> There are many platforms where a commercial compiler is preferable
> to gcc.
Please name a few (and the reasons why) :-)
BTW, GCC, for the most part, is a commercial compiler. I know
compilers wich are much worse that gcc on almost every aspect. In C++
standard compliance, gcc is the second best at close distance from the
EDG folks. If good C++ support is a need for a project, gcc is very
atractive, better than Borland (and _much_ better than MSVC). GCC is
better supported than some commercial compilers (ex. Borland). GCC
allows you to use the same compiler on almost every target you can
> > In what sense not adding M_PI takes #ifdefs away? Its absence just imp=
> > more #ifdefs!!
> Well, my comment was more general than just M_PI, I also referred to
> the stuff in libmingw32.
Ok. We were talking about M_PI :-) I guess that everybody agrees that
the stuff specific to mingw should be on its own headers and
> As for M_PI, as one cannot be sure that it exists on all platforms,
> isn't it simplest to define in an own header file a FOO_PI constant,
> and use that? (One hopes Pi has the same value on all platforms ;-)
Let's think on this scenario: you take a MSVC source and try to build
it. It's very unlikely that the build will fail because math.h has
M_PI. Now take a gcc source. If the project uses M_PI you have
OTOH, the standard headers should contain only the stuff mandated by
the standard, so both options are valid, IMO. What I can't afford is
using MSVC as "the Standard".
> > Assuming that MinGW is just a cheap replacement for MSVC is a rather
> > simplistic view.
> But it *is*, isn't it?
Speaking for myself, a big NO.
> I know for sure that if money was no objective, I would presumably
> use some other compiler, like Intel's, because I naturally want
> compiled code I distribute to be as fast as possible.
GCC's code is not so bad (and Intel has a prestige of generating
erroneous code). Gcc has other advantages over Intel.
> > There are several advantages that gcc has over MSVC, and
> > due to its open source better, that is the trend.
> Is it?
Yes, it is :-)
> > Sorry but it doesn't affect the compatibility. Your notion of
> > compatibility is completely wrong. MSVC compatibility means that stuff
> > made for MSVC compiles on MingW, and not the other way around!
> Why not? You think that "I write code for gcc. Other compiler users
> can go screw themselves" is a healthy attitude?
See above. This modification will not prevent using your code with
> > Bad PR is trying to sell the image of MinGW as a cheap replacement
> > for MSVC...
> Is it better PR to sell the image of MinGW as a compiler that has
> nifty extensions that locks you in to using gcc on all platforms?
You are free of choosing to use or not to use M_PI and similar
BTW, MSVC _has_ a long history of locking users ;-)
> I don't think people in general choose compilers for philosophical
> reasons. They choose one that is available for their target
That's an obvious requirement...
> that generates good code,
... this is a not-so-requested feature (at least on the C++ world)...
> and that they can afford.
Hmmm... If you are a pro, the cost of a compiler is not an issue. If
you are a hobyist, pretending that the available free options should
mimic what your favourite commercial vendor does is not fair, IMHO.
> Do you really think some company developing multi-platform software
> in C would choose gcc just because it's Free Software,
Most people I know doesn't choose GCC because it's Free Software, but
because it has a number of virtues that makes it preferable to other
options. Some of that virtues are consequence of GCC beaing Free
> if some (proprietary) platform-specific compilers would make their
> app run faster on that platform? (I said C, so the code in question
> would compile with any standard-conformant compiler.)
Personally, the performance of the compiled code is just a factor
among others one has to balance. The Intel compiler is available for
Linux. However, most commercial Linux shops I know are using gcc. (and
'Free' in "Free Software" is like "free speech", not "free beer")
> > Sure, but shouldn't you have in mind that not all people are trying to=
> > MinGW to replace MSVC either? They could be trying to use MinGW with c=
> > for unix, for borland c compilers, for lcc, watcom, djgpp, etc. What i=
> > special about MSVC that makes you ignore all the other compilers?
> Umm, I don't follow you here. I am not ignoring the other
> compilers. But MSVC is the dominant Win32 compiler in the commercial
> world, isn't it?
> If one wants some useful Open Source code library to
> have a chance of being introduced into some company, surely one
> shouldn't start by demanding them to switch compilers?
No need for switching compilers. Learn how to avoid vendor-specific
features, how to avoid vendor-specific bugs, etc.
> > Nevertheless, I strongly disagree with the philosophy of
> > feature-by-feature, bug-by-bug imitation of MSVC..
> Feature-by-feature yes, bug-by-bug of course not.=20
Oh my! The mingw team must be shuddering reading this :-) MSVC uses
_bugs_ as _features_. MSVC intentionally deviates from the
standards. MSVC introduces so many extensions and quirks that it's
practically impossible to chase them before the next release.
If you think this way and can't afford MSVC, try the Borland free
compiler. It even can compile most MFC code, suports structured
exceptions, etc. It defines M_PI on math.h, though <g>
Seriously, I think you are wrong and you can develop good portable
libraries with mingw.
> > It seems that one of these days one will type 'cl' instead of 'gcc' for
> > starting the compiler and MinGW will just be called MiGW: Msvc Imitati=
> > with Gcc on Windows...
> Umm, of course not. What would be useful, though, is a cl (or icc,
> etc) wrapper that turns gcc-style switches into cl (or icc) ones and
> invokes cl (icc).=20
This is hard to do for the general case.
MinGW has an identity by itself, it is not MSVC. And I'm happy about
> That would make using other compilers with typical
> Makefiles easier. There are several good reasons why some people
> prefer other compilers.
And there are several good reasong why some people prefer mingw over