User forums > General (but related to Code::Blocks)

pro's and pre's of compilers

<< < (2/7) > >>

Urxae:
First of all, I didn't say it can't be ported, I just said it would be easier if you could use the same compiler on all the platforms.
I've read a lot of thread on other forums by people trying to port their programs to Linux/BSD/whatever and the fact they used VC++ factored into it, if only because they did use VC++-specific stuff. If it's there, a lot of people will use it and either not even realize it's not portable or not care it isn't until it's too late.

David Perfors:
I am downloading the other compilers which are supported by C::B. I am going to compile wxWidgets and going to time it, and look what the size is...

Vampyre_Dark:

--- Quote from: fvbommel ---First of all, I didn't say it can't be ported, I just said it would be easier if you could use the same compiler on all the platforms.
I've read a lot of thread on other forums by people trying to port their programs to Linux/BSD/whatever and the fact they used VC++ factored into it, if only because they did use VC++-specific stuff. If it's there, a lot of people will use it and either not even realize it's not portable or not care it isn't until it's too late.
--- End quote ---
It wasn't the fact that they used VC++, it was the fact that they used windows specific code and libraries. The same is possible is MinGW and just as easy.

If you use SDL, and OpenGL in VC++, it's not any less portable than MinGW. However, the VC++ toolkit makes it easy to actually use all the windows stuff(like DirectX) out there, where supporting MinGW is a non factor.

I think it gives better error and warning messages too. :oops: MSInput said he wanted to compile wxwindows anyways, so perhaps those were moot points.

mandrav:

--- Quote from: mispunt ---I am downloading the other compilers which are supported by C::B. I am going to compile wxWidgets and going to time it, and look what the size is...
--- End quote ---

To save you the trouble (for other than educational purposes), check this page for wxWidgets compile speed comparison between most major compilers.
And the winner is... DigitalMars, hands-down :)
I mean, 2.5 minutes to build wxWidgets is just awesome!

Yiannis.

thomas:
gcc it is, undoubtly.

It may not always do  the very fastest compiling, and it may not always be the top performer, granted.
However, it is unarguably the best general and portable compiler suite by design and philosophy.
First of all, a compiler should be correct, and then it should be optimized, as a correct compiler enables you to produce much better code in the end.

One of the major design failures in wxWindows in my opinion is that they use macros for everything and reimplement STL functionality with custom classes. The reason they state is "portability".
The real reason is templates *are* portable, and the STL *is* portable (well, 95%), only MSVC is utterly broken.
By using and supporting MSVC, you prove them correct and further the development of incorrect software. At the same time, you prevent others from writing correct code because they must take VC into account.
It is like designing a web page for Internet Explorer. If you "optimize" your web sites for Internet Explorer, then your markup is not only incorrect, it also encourages the production of web browsers which honour flashy features higher than security and standard compliance. And, more seriously, you penaltize those browsers that are actually correct, as these will not show the pages the way people expect them.

For this reason, and to honour the free time the gcc developers sacrifice to produce a really good product (which they give to the world for free), one should use gcc.

Call me a Hippie if you like, I don't mind (and yes, I use OpenGL, too)  :)

Executable speed may be an issue for some, however, the really big difference in performance lies in entirely other things, anyway. The actual gains by using another compiler are rather small. Other things can easily make a difference of factor 2, 10, 100, or 1000, where compilers make a difference of 5%. Think of algorithm complexity, multiple API layers, cache misses, page faults, synchronous disk access... the compiler is really the smallest factor here.

Compile times, well, yes, gcc is somewhat slow. But you have to be fair and admit that at least some of this is due to precompilation. If you have gcc precompile your headers, your compile times are somewhat faster, too. Unluckily, the one thing that would benefit most from that is wx again, and wx throws up errors on precompilation.
Either way, most of my projects build in 20-40 seconds on gcc (without optimizations of course), and when only changing 1-2 files, it takes some 3-4 seconds, which is quite acceptable. What difference does it make if one single file compiles in 1.1 or 1.5 seconds.
If an optimized revision build takes 5-6 minutes, so what... you don't do that 50 times per day ;)

As a sidenote, I am curious to see how things will change with gcc 4.0, as the optimizer has seen a major overhaul and the 4.0 version supports auto-vectorization (is there any other compiler supporting this?). The effect of auto-vectorization may be zero for many applications, but it may as well be a great benefit for anything that processes mid-size or large-size streams of data. As it happens, it may save me a lot of hand-coded SSE assembly (which the compiler possibly can do better, too).

Navigation

[0] Message Index

[#] Next page

[*] Previous page