views:

716

answers:

13

I'm interested in different aspects of portability (as you can see when browsing my other questions), so I read a lot about it. Quite often, I read/hear that Code should be written in a way that makes it compilable on different compilers.

Without any real life experience with gcc / g++, it seems to me that it supports every major platform one can imagine, so Code that compiles on g++ can run on almost any system. So why would someone bother to have his code run on the MS Compiler, the Intel compiler and others?

I can think of some reasons, too. As the FAQ suggest, I'll try to post them as an answer, opposed to including them into my own question.

Edit: Conclusion

You people got me completely convinced that there are several good reasons to support multiple compilers. There are so many reasons that it was hard to choose an answer to be the accepted one. The most important reasons for me:

  • Contributors are much more likely to work an my project or just use it if they can use the compiler of their choice
  • Being compilable everywhere, being usable with future compilers and tools, and adhering to the standards are enforcing each other, so it's a good idea

On the other hand, I still believe that there are other things which are more important, and now I know that sometimes it isn't important at all.

And last of all, there was no single answer that could convince me not to choose GCC as the primary or default compiler for my project.

+12  A: 

Portability. If you want your code to be accessible by the maximum number of people possible, you have to make it work on the widest range of possible compilers. It the same idea as make a web site run on browsers other than IE.

Some of it is political. Companies have standards, people have favorite tools etc. Telling someone that they should use X, really puts some people off, and makes it really inaccessible to others.

Nemanja brings up a good point too, targeting for a certain compiler locks you into to using it. In the Open Source world, this might not be as big of a problem (although people could just stop developing on it and it becomes obsolete), but what if the company you buy it from discontinues the product, or goes out of business?

Kevin
+18  A: 

Some reasons from the top of my head:

1) To avoid being locked with a single compiler vendor (open source or not).

2) Compiling code with different compilers is likely to discover more errors: warnings are different and different compilers support the Standard to a different degree.

Nemanja Trifunovic
The second point is very true; back when I was supporting multiple platforms, I found a number of errors that were caught by one compiler but ignored by the others.
John Bode
+4  A: 

It's very common for applications (especially open-source application) that other developers would desire to use different compilers. Some would rather be using Visual Studio with MS Compiler for development purposes. Some would rather use Intel compiler for claimed performance benefits and such.

notnoop
+5  A: 

If you are building for different platforms, you will end up using different compilers. Moreover, C++ compilers tend to be always slightly behind the C++ standard, which means they usually change their adherence to it as time passes. If you target the common denominator to all major compilers then the code maintenance cost will be lower.

pau.estalella
+3  A: 

So here are the reasons I can think of

  • if speed is the biggest concern and there is special, highly optimized compiler for some platforms
  • if you build a library with a C++ interface (classes and templates, instead of just functions). Because of name mangling and other stuff, the library must be compiled with the same compiler as the client code, and if the client wants to use Visual C++, he must be able to compile the lib with it
  • if you want to support some very rare platform that does not have gcc support

(For me, those reasons are not significant, since I want to build a library that uses C++ internally, but has a C interface.)

Brian Schimmel
Do you want to build an open-source library? Then it'll need to compile on anything. Do you want to be stuck using G++ 4.4 when G++ 7 is around and can turn your 13-class "Hello world" program into a 52-byte binary? Then you'll need to write standards-compliant C++, which means you should compile with many compilers to make sure you don't get stuck with something G++ supports but no one else does (or that they supported but no longer do, so you have to either rewrite all your code, or compile with a dated compiler).
Chris Lutz
+12  A: 

It is good to be compilable on MSVC, because some people may have projects that they build in MSVC that they want to link your code into, without having to set up an entirely different build system.

It is good to be compilable under the Intel compiler, because it frequently compiles faster code.

It is good to be compilable under Clang, because it can give better error messages and provide a better development experience, and it is an easier project to work on than GCC and so may gain additional benefits in the future.

In general, it is good to keep your options open, because there is no one compiler that fits all needs. GCC is a good compiler, and is great for most purposes, but you sometimes need something else.

And even if you're usually only going to be compiling under GCC, making sure your code compiles under other compilers is also likely to help find problems that could prevent your code from working with past and future versions of GCC, for instance, if there's something that GCC is less strict about now, but later adds checks for, another compiler may catch in advance, helping you keep your code cleaner. I've found this helpful in the reverse case, where GCC caught more potential problems with warnings than MSVC did (MSVC is the only compiler we needed to support, as we were only shipping on Windows, but we did a partial port to the Mac under GCC in our free time), which allowed me to produce cleaner code than I would have otherwise.

Brian Campbell
Devil's advocate: these seem mostly hypothetical. If I'm not using MSVC, then why would that be in the top 90% of my priority list? Unless I need a speed boost that only ICC can provide (when was the last time compiler optimization was a bottleneck?), why would I care about that? And so on. Every non-trivial project has at least hundreds of open bugs in their bug tracker -- none of the projects I work on has the problem that we can't find enough bugs with only one compiler. Why would finding potential bugs or helping out potential users ever be more important than working on actual issues?
Ken
It wouldn't. Fix your actual issues. That is, in the end, more important. The OP asked why it's important to compile C or C++ code with different compilers, and I gave him some reasons, but it's more important to provide core functionality, features, and bug fixes to your user base.
Brian Campbell
Sure you have bugs in your tracker, but you may only know their effects, not their cause. A different compiler might detect a bug that is actually the *cause* of 15 bugs in your tracker. Or it may expose an undiscovered show-stopper that would otherwise screw your users once released.Having more bugs than you can handle is no reason to stick your head in the sand. There are more and less important bugs, after all.
uliwitness
Brian: But do you ever run out of actual issues? uliwitness: I can't remember the last time I saw a bug I didn't know the cause of -- debuggers and logging are pretty darned good these days, compared to what we used to have. And "stick(ing my) head in the sand" is a funny way to refer to "fixing actual issues".
Ken
Congratulations, I envy you for whatever problem domain your apps work in. I work on TV software, and there are enough hardware/driver/driver support bugs to work around, as well as complex decoder and player issues (particularly regarding signal interference or nonstandard encodes), that more often than not you spend a few weeks tracking down the source of a problem (or even just a reproducible test case). Having the compiler raise a flag that, this time, it's really just a typo in the code can be very helpful.
uliwitness
uliwitness: I'm not sure who you're addressing there, but I'll respond to your comment. It can be useful to port your program to other compilers and libraries. But it can also be a lot of work; there are just some gratuitous differences that don't matter at all to your program, but which are necessary for getting it to compile on a different compiler. And in some code bases, you may not have the types of bugs that a different compiler with different warnings will catch (only some bugs will be caught by that, and you have no guarantee going into the process that you'll find such bugs).
Brian Campbell
+4  A: 

Typically these are the reasons that I've found:

  • cross-platform (windows, linux, mac)
  • different developers doing development on different OS's (while not optimal, it does happen - testing usually takes place on the target platform only).
  • Compiler companies go out of business - or stop development on that language. If you know your program compiles/runs well using another compiler, you've covered your bet.

I'm sure there are other answers as well, but these are the most common reasons I've run into so far.

ssnyder
+4  A: 

This one of those "It depends" questions. For open source code, it's good to be portable to multiple compilers. After all having people in diverse environments build the code is sort of the point.

But for closed source, This is a lot less important. You never want to unnecessarily tie yourself to a specific compiler. But in most of the places I've worked, compiler portability didn't even make into the top 10 of things we cared about. Even if you never use anything other than standerd C/C++, switching a large code base to a new compiler is a dangerous thing to do. Compilers have bugs. Sometimes your code will have bugs that are benign on one compiler, but suddenly a problem on another.

I remember one transition, where one compiler thought this code was just fine:

for (int ii = 0; ii < n; ++ii) { /* some code */ }
for (int ii = 0; ii < y; ++ii) { /* some other code */ }

While the newer compiler complained that ii had been declared twice, so we had to go through all of our code and declare loop variables before the loop in order to switch.

One place I worked was so careful about unintended side effects of compiler switches, that they checked specific compilers into each source tree, and once the code shipped would only use that one compiler to do updates on that code base - forever.

Another place would try out a new compiler for 6 months to a year before they switched over to it.

John Knoeller
"One place I worked was " ... possibly because the code did things that were strictly undefined according to the C/C++ spec; e.g. like making invalid assumptions about order of execution in expressions. If your code runs with some compiler optimization switches and not others, that's most likely a bug in your code.
Stephen C
+1  A: 

Both Intel compiler and llvm are faster than gcc. The real reasons to use gcc are

  • Infinite hardware support (on no other compiler can you compile a lego mindstorm code on your old DEC).

  • it's cheap

  • best spagety optimizer in the business.

David Lehavi
+4  A: 

Several projects use GCC/G++ as a "day-to-day" compiler for normal use, but every so often will check to make sure their code follows the standards with the Comeau C/C++ compiler. Their website looks like a nightmare, and the compiler isn't free, but it's known as possibly the most standards-compliant compiler around, and will warn you about things many compilers will silently accept or explicitly allow as a nonstandard extension (yes, I'm looking at you, Mr. I-don't-mind-and-actually-actively-support-your-efforts-to-do-pointer-arithmetic-on-void-pointers-GCC).

Compiling every so often with a compiler as strict as Comeau (or, even better, compiling with as many compilers as you can get your hands on) will let you know of errors people might experience when trying to compile your code, things your compiler allows you to do that it shouldn't, and potentially things that other compilers don't allow you to do that you should. Writing ANSI C or C++ should be an important goal for code you intend to use on multiple platforms, and using the most standards-compliant compiler around is a good way to do that.

(Disclaimer: I don't have Comeau, and don't plan on getting it, and can't get it because I'm on OS X. I do C, not C++, so I can actually know the whole language, and the average C compiler is much closer to the C standard than the average C++ compiler to the C++ standard, so it's less of an issue for me. Just wanted to put this in here because this started to look like an ad for Comeau. It should be seen more as an ad for compiling with many different compilers.)

Chris Lutz
+2  A: 

I find gcc a slow compiler on windows (nothing to compare against under linux). So I (sometimes) want to compile my code under other compilers, just for faster development cycles.

elcuco
I thought it's fastest in Windows too ... I'm using MinGW in Windows ... it's faster than MS C++ compiler I think !!!
Michel Kogan
Compiling Qt4 from git under MSVC 2009 it takes me 3 hours. With MinGW between 5 and 6. I don't think mingw/gcc is slower on windows: I KNOW IT, I HAVE MEASURED IT.
elcuco
I now made new measures, using Visual Studio 2007 (cl.exe) and GCC 4.4.1 (TDM) - and now they are very close, one or two minutes difference. GCC is getting better.
elcuco
+6  A: 
Norman Ramsey
It's very interesting to hear that Linux story from you, because of course I hope that my project will be as successful as Linux. (which programmer doesn't? ;) ) But in the beginning, it first has to become that successful, so I'd rather do what I can to make it compilable on the most common compilers, so that many people can use it and participate. And even though I hope for success, it is never guaranteed and doesn't come without efforts, so I better have a "plan B" for being unsuccessful.
Brian Schimmel
+2  A: 

I don't think anyone has mentioned it so far, but another reason may be access to certain platform-specific features: Many operating system vendors have special versions of GCC, or even their own home-grown (or licensed and modified) compilers. So if you want your code to run well on several platforms, you may need to choose the right compiler on each platform. Be that an embedded system, MacOS, Windows etc.

Also, speed may be an issue (both compilation speed and execution speed). Back in the PPC days, GCC produced notoriously slow code on PowerPC CPUs, so Apple put a bunch of engineers on GCC to improve that (GCC was very new for the Mac, and all other PowerPC platforms were small). Platforms that are used less may be optimized less in GCC, so using another compiler that's been written for that platform can be faster.

But as a final summary: While there is ideal value in compiling on several compilers, in practice, this is mainly interesting for cross-platform software (and open-source software, because it often gets made cross-platform fairly quickly, and contributors have it easier if they can use their compiler of choice instead of having to learn a new one). If you need to ship on one platform only, shipping and maintenance are usually much more important than investing in building on several compilers if you're only releasing the builds made with one of them. However, you will want to clearly document any deviations from the standard (GCC-isms, for instance) to make the job of porting easier, should you ever have to do it.

uliwitness