Any modern text editor does that.

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.

Just what bad practices are you referring to?

Most tools in an IDE are available as standalone tools so which of these tools should in your view be avoided?

I never heard of clang. I guess I should find some time to investigate. I've tried several other compilers, most worse than gcc.

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.

2 members found this post helpful.

Well, since I seem to be under pressure to provide examples, I'll happily do so

Here are some known bugs:
http://gcc.gnu.org/bugs/#known

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).

Some of the issues between pre-ISO C and current C have caught me, but that's because I'm old and have worked on some VERY old C programs. YMMV on these: http://gcc.gnu.org/onlinedocs/gcc/In...ompatibilities

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 some 'philosophical' differences enumerated here that you may run into: http://gcc.gnu.org/onlinedocs/gcc/No...l#Non_002dbugs

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

With '-Wall -Wextra' unused variables are reported during compilation.

1 members found this post helpful.

Thanks! I hadn't tried that one

C++! C# = m$.

1 members found this post helpful.

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.

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.

1 members found this post helpful.

Yes!

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.

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).