Secondly by it's very nature and as made obvious by their name, extensions AREN'T standards, they are 'extensions' to existing standards, how can you fail to grasp that? And those who use these 'extensions' do so because they really feel they need what they offer, knowing full and well that there is no guaranteed compability across compiler toolchains given that they are NOT standards.
Also, you do realize that most of the features in later standards started as extensions and then elevated into standard functionality when they had proven their worth and stability?
In conclusion, both GCC, Clang/LLVM, Intel Compiler implements compiler _extensions_ which offer functionality beyond what the standards define. These _extensions_ are not supported across all compilers although some are, GCC has exclusively supported extensions, Clang/LLVM has exclusively supported extensions and same goes for ICC.
I find it hard to believe you are a programmer at all, you sound like a person who just compiles other people's code and throws a fit if it doesn't compile with *your* favourite compiler. And if you feel you have a legitimate reason to complain then you should take those complaints to the actual programmers who CHOSE to USE these extensions, not to the compiler vendors who make them available at the request of those same programmers. And you should certainly not single out GCC as some culprit, because all these compilers implement extensions and each with their own exclusive ones.
If you make a compiler that meets just the standards instead of making what people actually need, you've made something that's a whole heap of worthless.
The assumption that the standards are good enough is obviously incorrect as if that was true then there would be no need for extensions.
Last edited by Sidicas; 02-16-2012 at 02:57 PM.
And while compiler extensions can prevent code from being portable between compilers, how will it make open source not 'open' or free open source not 'free'? Your ignorance and Linux hatred seems to know no bounds, certainly reality has no effect on it.
I don't see that at all.For those wanting to see another polarized discussion
What I see is:
One Guy: "Hey I heard about this thing and I want you do to a bunch of really hard, time consuming, and irritating work to see if we can do something in a worse way then you already do!"
Rest of them: "Uhhh... no."
ISTR that some of gnu89 wound up in C99, and some of gnu99 ended up in C11 (I think I saw it in one of the man pages...).
Which means that today's gnu extensions are tomorrow's standard.
One person ( developer working on compiling Linux with LLVM) mentioned that while LLVM can build a minimal kernel, it can't even make a bootable no-op kernel.
A number of "kernel bugs" were related to compiler optimizations that did the wrong thing (eg, null pointer check got optimized out); the fix was to put in a directive that disabled the optimization there. Just because GCC did the wrong thing and a bug was found in one use, doesn't mean that noone else will make the same mistake; the tricks work in certain other contexts, so the GCC developers aren't reverting them. Thus you end up using extensions to work around a slightly broken compiler.
When someone offers you a compiler which, for your purposes, is even more broken (isn't Apple is supporting OSX and not Linux?), but doesn't have all the methods to workaround stuff semi-sanely, you would end up getting more breakage if you support it: first, you lose fixes for your own compiler; second, people try the other compiler, it doesn't work right, and there aren't as many people working on the project using either compiler as there were using the one compiler you started with (If you start with 100 programmers, and 20 switch, and 10 join them, you have 80 people to support one and 30 to support the other, so you get breakage on one or the other, or fixes get hung up, and you get some bitrot in the less-used compiler branch).
Using compiler extensions when they aren't needed really is a bad thing. Using them when they are needed, is not.
Clang already supports many of the GCC extensions because everyone recognizes that they are useful, and it's nice for the two projects to be compatible. They've also said that a few were poorly designed and will not be implemented.
As LLVM matures compatibility will continue to increase, and I haven't really seen any projects that are refusing to take contributions to fix up Clang compatibility. If something isn't working correctly, just patch the project with #ifdefs to get it working. That's one of the benefits of being open source, that anyone with an interest can go in and fix up their pet peeves.
This is the problem with almost every major language outside the C/C++/C# family: they're filled to the brim with half-thought-out idiocy that some so-called compiler expert dropped in because the idea popped into his head. Rarely are these features analyzed to see just how generic, safe, or consistent they are. Everyone who pretends to be a compiler expert seems to be obsessed with writing excessively terse (read: unmaintainable) code and adding syntactic sugar to make it happen. Craziness.
There's no reason to use those. Use the standardized CPU intrinsics. (Yes, they are standardized by Intel/ARM/IBM.)I can't recall ever having use of anything other than the gcc vector type extensions
Yes. Those language updates explicitly add features that allow the programmer or compiler to do things that were literally _impossible_ to do before. The standards committees that are now in charge of those languages (C++ was for a long time under no such authority, and some of the goofier bits of the language appeared during those years) are full of a lot of very smart people, who are _very_ conservative in what they add to the languages, and they only do so when there is truly remarkable utility in doing so.Is C99 necessary? C11? C++11?
If they want to target MSVC 2010, then no, they should not.Should programmers not use the features offered by them if their compiler supports it because say VS2010 doesn't support them fully?
Should programmers not use Win32 APIs if their OS (Linux) doesn't support them fully?
And not just random extensions (it has an unfortunate number of those too) but is being used as a testbed for features that will be proposed to the committees. Which is one of the reasons why dipshits who think Clang is just "Apple crap" are dipshits. Clang has a LOT of incredible benefits over GCC. The fact that it can't compile every random low-quality FOSS crap package, or the fact that it does not _yet_ optimize as well as a much older compiler, is of little importance to some users. The fact that it's massively easier to alter and extend, that it provides incredibly more logical error messages, that it allows much richer plugins and non-compiler uses than GCC, that it was designed to be easy to use for editors and tools (which are more important than the compiler itself, IMO, and in the common opinions of anyone who actually maintains large and complex codebases)... these are why Clang is so awesome.And for the record Clang supports lots of extensions, so it's not 'pure' by any means.
Should Fedora switch to using it by default? No. As the Fedora folks said, there's little reason at this point in time. Clang is in the Fedora package repo, and the people and projects and tools that can make good use of it do so.