adding C++11 features to GCC is a far more difficult undertaking than it should be because of RMS and his fear of proprietary frontends to GCC (so the plugin system, which is relatively easy to work with in LLVM, is a nightmare in GCC). That was a design decision
Quote:
"The concern that has long been expressed by the FSF (which owns the copyrights on GCC) is that a general plugin mechanism would make it possible for companies to traffic in binary-only GCC modules. Rather than contribute a new analysis or optimization tool - or a new language - to the community, companies might have an incentive to distribute their work separately under a restrictive license. That runs very much counter to what the FSF is trying to accomplish, so opposition from that direction is not particularly surprising."
> adding C++11 features to GCC is a far more difficult undertaking than it should be because of RMS and his fear of proprietary frontends to GCC
Whatever you think of RMS's stance on plugins, or gcc's plugin system, they have little relationship with the ease or otherwise of adding C++11 features to gcc.
The latter has much more to do with the difficulty of understanding the gcc C++11 front end, the difficulty of understanding the fine details of the C++11 standard sufficiently to implement it, and the amount of manpower available from people who can do both those things (or who have the time to learn).
gcc certainly does have a lot of historical baggage in its code base (though this is slowly improving with time), but given its rather complete support for C++11 (on par with clang certainly, and far ahead of MS's compiler and most other proprietary C++ compilers), they're not doing so bad...
No, RMS's stance of plugins does make adding C++11 features to gcc much harder.
I have a (basic) understand of clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM, which I can ignore the other side of. The interface between gcc front ends and backends is none of clear, simple or documented.
> No, RMS's stance of plugins does make adding C++11 features to gcc much harder
> clang, which is helped by the fact that there is a very clear, simple and DOCUMENTED boundary into LLVM
(1) People adding C++11 features to clang are not going to be dealing with LLVM, they're going to be modifying and extending clang's existing C++ parser. So however nice the clang-LLVM front-end-middle-end interface is, that's not going to have much impact on this job. Rather, what's important is the quality of clang's internal algorithms and data-structures (and those in gcc's c++ front-end). If clang does better there (dunno), that's great for them, but it has nothing to do with RMS's plugin position.
(2) RMS is not against clean code, nice interfaces, good data structures, and good documentation. His concerns (whether you agree with them or not) are the degree to which interfaces are expressed in a way that circumvents the GPL. Good interfaces don't circumvent the GPL;
So it's perfectly fine to clean up and document gcc's data structures and interfaces (and indeed, this is already happening, and has been for a long time). RMS isn't going to stop you.
"GCC suffers from layering problems and leaky abstractions: the back end walks front-end ASTs to generate debug info, the front ends generate back-end data structures, and the entire compiler depends on global data structures set up by the command line interface."
No, I'm suggesting that understanding and modifying the C++ front end is much easier when the output the front-end produces is in well defined and documented output, rather than the ad-hoc and undocumented results of a gcc front-end.
Have you scrolled down that page? It is an extremely brief introduction. The 'types' and 'functions' sections are completely empty, and the whole page amounts to 2 examples!
There's more at http://gcc.gnu.org/wiki/GENERIC: my purpose was more to point out that an interface exists than to pinpoint the exact documents for you.
