ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I must mention that GCC/G++ is a freaking mess. You'll end up making quite a few tweaks to optimize your code for the compiler rather than the other way around.
This is a nonsense statement; however if you'd care to back it up with some examples then maybe it has some merit to it. I regularly use g++ and have not had to knowingly tweak my code.
I must mention that GCC/G++ is a freaking mess. You'll end up making quite a few tweaks to optimize your code for the compiler rather than the other way around. You might want to try clang or some of the other ones.
I never heard of clang. I guess I should find some time to investigate. I've tried several other compilers, most worse than gcc.
Quote:
Originally Posted by graemef
This is a nonsense statement; however if you'd care to back it up with some examples then maybe it has some merit to it. I regularly use g++ and have not had to knowingly tweak my code.
I was also wondering about what was behind that claim about GCC.
GCC, even for 32 bit X86, is a pretty good compiler with decent optimization. Very few programmers work much on projects where it is justified to push for a higher level of optimization than you get by simply using GCC and turning on some optimization.
I happen to do a lot of programming in which extreme effort for optimization is justified. For that reason, I wouldn't even touch GCC for 32 bit X86. I wouldn't touch any MS compiler for 32 bit X86 either. There is an obsolete version of Windows ICC so much better than anything else for 32 bit X86 that other choices just aren't appropriate. Even in Linux, where that version of ICC isn't available, newer inferior versions of ICC still blow away GCC or anything else I've tried.
But where performance matters most, you probably want to use X86_64, not X86. There GCC does not have the solid disadvantage vs. ICC.
Quite a while ago, I did a very serious performance comparison between GCC 4.3.2 and ICC 10 for X86_64. Before serious tweaking of code or command line switches, ICC blew away GCC.
Quite a lot of effort tweaking the code and command line switches for ICC yielded only modest improvement. ICC is incredibly resistant to any kind of programmer driven optimization. If it is going to make a terrible choice about whether to inline a function or not (as it often does) there is usually no reasonable way to change its mind.
With GCC, moderate effort at tweaking the code and command line switches yielded dramatic results. Some modules still performed worse than with ICC even after such tweaks. Others performed much better. Overall the results were very similar.
I believe GCC has improved more since 4.3.2 than ICC has since 10. But I'm not certain of that and don't have time for another such comparison.
Back on the claim I'm responding to "quite a few tweaks to optimize your code for the compiler", I think that is actually true of GCC for the rare case that it is justified to push for maximum optimization. But most projects don't justify that effort and most other compilers (only maybe excepting ICC) can't hit those performance levels at all and/or without similar code tweaks.
There are rounding bugs (like the infamous 10 year old bug 323) - and not all compilers will produce the same results for the same numbers. Make sure to handle precision properly!
There are minor 'grammatical' differences in how it handles existing code (due to slight differences in interpreting the complex language spec), like name lookup (which changed slightly due to a compiler bug) http://gcc.gnu.org/onlinedocs/gcc/Na...ml#Name-lookup
It doesn't follow updated headers, because it uses some shell scripts to hack around the headers. Not really a bug, more of an inconvenience (this isn't the case under XCode, the various MS IDEs, etc since they handle the installs/updates better).
There are a LOT of issues with AIX (which I support professionally), though most people don't use gcc/g++ on AIX. They use IBM's tools which produce better performing code on POWER anyhow.
There are typically sets of package compilation failures each time g++ is upgraded (due to its lovely habit of slightly changing how it interprets the rules each version) - I can provide examples from the *BSD trees if you like, but that would belabor the point I think.
Now before people with too much time go on a lovely tear with this in a newbie coding thread, I'm just going to say: For a newbie, most of these issues are minor. Hello World will compile just fine on gcc/g++. Any program that doesn't require high levels of precision or really careful timing will run fine. Newly written code doesn't have the same issues as gigantic legacy code sets.
I have to write and maintain code for VMS Alpha, AIX POWER, Solaris SPARC, Solaris x86_64, plus Linux, FreeBSD, and OSX(PPC and x86) and so I run into some serious inconveniences between the various implementations. Stuff will warn on one system and not the other. Timer loops (not a really good idea, but some of the legacy code has it) can disappear depending on the compiler. Floats round differently (so remember that floats get rounded!). GDB doesn't debug empty vars, which can be frustrating if you didn't realize it was supposed to be empty (again an issue with supporting legacy code).
The number one issue I have though is that code you wrote and optimized against one version of gcc may warn or fail in the next version. To be honest, this isn't really their fault, it's because the spec is complex and not always implemented properly. If you weren't paying close attention to make sure your code was absolutely 'standard' you may get bitten. Can't really fault them for that.
Yay for pedantic compiler arguments. For these and many others, go follow the compiler mailing lists
...
GDB doesn't debug empty vars, which can be frustrating if you didn't realize it was supposed to be empty (again an issue with supporting legacy code).
...
With '-Wall -Wextra' unused variables are reported during compilation.
By the way, a lot of legacy code can not be compiled with newer 'gcc' - a lot of formally invalid C/C++ code in the code.
That's why, even though I myself build 'gcc' and have the newest stable one, I also have gcc-3.4.6 around. And for some code even gcc-3.4.6 is too new.
By the way, a lot of legacy code can not be compiled with newer 'gcc' - a lot of formally invalid C/C++ code in the code.
That's why, even though I myself build 'gcc' and have the newest stable one, I also have gcc-3.4.6 around. And for some code even gcc-3.4.6 is too new.
This is very true. I have similar problems with code that was for the Intel, Sun, or IBM specific compilers. Even though our mandate is "ANSI Standard C/C++" I still spend time cursing because __whatever__ isn't there, or means something else, or whatnot.
I find that when writing complex programs (500k+ lines) you end up really married to your compiler. Changing it can be *far* more expensive than a simple license fee.
I find that when writing complex programs (500k+ lines) you end up really married to your compiler. Changing it can be *far* more expensive than a simple license fee.
In my own much smaller piece of code written for myself only I explicitly mark with comments pieces of code which are 'gcc' specific. So far it's mostly big array initialization.
Other than that it's C99 and in some cases even C89 (== ANSI C).
The company is to blame itself for lack of code reviews.
Because C# is interpreted, it will hinder performance. Or at least it needs a runtime environment to run - a problem indeed. Plain C or C++ will (sort of) do the trick, or, if you want, Go will also do the trick - if you can tolerate defining most of your code instead of relying on a library.
Well, since I seem to be under pressure to provide examples, I'll happily do so
Thanks for clarifying your statement. I reacted the way that I did because of the genaralisation of your statement. Whereas you raise some valid points, I would suggest that developing on multiple platforms supporting legacy code is probably not the norm. Additionally I don't think that it is appropriate (without explanation) when comparing C++ to C#.
Thanks for clarifying your statement. I reacted the way that I did because of the genaralisation of your statement. Whereas you raise some valid points, I would suggest that developing on multiple platforms supporting legacy code is probably not the norm. Additionally I don't think that it is appropriate (without explanation) when comparing C++ to C#.
Entirely reasonable. I think it is the norm, because my work supporting Gnome for FreeBSD involves supporting all the platforms that FreeBSD supports. Linux would have the same issues.
I would, in fact, argue that for Open Source development you will spend *more* time doing multi-platform support of a legacy code base than doing brand new coding for a single code base.
I envy the Windows guys - they have it easy. Even Mac guys should realistically be targeting PPC and Intel (though they have probably stopped doing that).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.