GCC Switches From C to C++ 406
According to a post on the GNU Compiler Collection list, GCC is now built as a C++ program by default. This is the fruition of much effort, and the goal now is to clean up the GCC internals that are reportedly pretty type-unsafe by rewriting them using C++ classes and templates.
Compiler bootstrapping? (Score:5, Interesting)
How will this affect bootstrapping the GCC on bare systems?
Been a while since I've delved into LFS or the like, but I'd think GCC being C++ based would seriously complicate things as it's now got more dependencies.
libgcc and libsupc++ (Score:4, Interesting)
What does a distribution license have to do with a compiler?
Division support in C on some platforms (such as ARM) and exception support in C++ rely on libraries called libgcc and libsupc++. These libraries are GPLv3 with an exception. Were it not for the exception, anything compiled with the would either be GPL (because of libgcc and libsupc++) or produce a linker error (because the libraries are called and not present). The exception applies only if the compiler has not been modified to introduce non-free optimization passes performed in an independent process. See GCC Exception FAQ [gnu.org].
Who does believes in GPL cuties? Apple, FreeBSD, 6 year olds, anybody else?
You can add Nintendo. See the case of Pajama Sam for Wii, where Atari was willing to distribute the source code to a GPL interpreter used for the game but Nintendo didn't want GPL software on its platform [slashdot.org].
Re:too bad GCC is not relevant anymore thanks to L (Score:5, Interesting)
AIUI GCC is now GPLv3, the libraries it ships with are GPLv3 with exceptions that allow using them to build non-GPL programs. However they were paranoid about the idea that people would try and save gcc's internal state to disk and then run it through a propietry backend. So they crafted a complex exception that tries to forbid that while allowing most other combinations of gcc with propietry tools.
bad_alloc (Score:2, Interesting)
or you have some very specific performance issues that you absolutely cannot fix any other way (and generally, you don't have this problem with the STL)
On a platform with no swap file, such as a handheld or set-top device, one of the more common "very specific performance issues" is the ability to handle allocator failures. A program in such an environment is supposed to free cached or otherwise purgeable resources instead of just letting main() catch std::bad_alloc and abort. What are best practices for using the C++ containers if virtual memory is not available?
Re:too bad GCC is not relevant anymore thanks to L (Score:5, Interesting)
Well, let's see. I personally work with control systems using x86, MIPS, PowerPC and ARM architectures, running Linux, VxWorks, QNX and WinCE (various combinations). They all have GCC toolchains, although we admittedly don't use it for CE.
If you're thinking microcontrollers, then GCC supports AVR, 68000-series, MicroBlaze, MSP430, ARM again...
Now, personally, my refrigerator has an analog thermostat, so, technically, you are right. If it had a thermostat implemented on a CPU, then I'd think there's a very good chance it was compiled with GCC.
What exactly "programmed in GCC" might mean is left for the reader to speculate on.
Re:Type unsafe... (Score:2, Interesting)
(not (quite_like (works LISP) you_say))
Re: progress (Score:2, Interesting)
I too would have seen a move from C to C++ as progress...
in 1989.
It took me til about 1990 to realize that C++ was a fundamentally broken and overcomplicated attempt at an object oriented programming language. By attempting too much (OO + C backward compatibility) it achieved, to be kind, something other than safety and elegance.
C++ seems to me like the space shuttle of programming languages; includes a kitchen sink, a tool on board for every purpose, lightning fast, and dangerous as hell.
So tell me, has 22 years more development managed to fix it?
Re: progress (Score:3, Interesting)
I too would have seen a move from C to C++ as progress...
in 1989.
It took me til about 1990 to realize that C++ was a fundamentally broken and overcomplicated attempt at an object oriented programming language. By attempting too much (OO + C backward compatibility) it achieved, to be kind, something other than safety and elegance.
Actually if it only had near-compatibility with C and OO, it would have been a very nice and useful language. But then things went south and they added too many overloadable operators, a nightmarish jumble of rules for typecasting/overload resolution, exceptions that can't be implemented properly in modern application software, but add a whole new dimension of concerns that the programmer should always be aware of... Then they topped it all off with hideously overcomplicated templates. The standard libraries mostly have crappy and/or misguided design: practically non-extensible, bloat-inducing iostream, the bloatware generation templates that used to be called STL, and so on.
So now, real-world projects that use C++ for the useful things it does provide have to maintain coding guidelines to avoid shooting themselves in the foot too often.
Re:RTFA (Score:4, Interesting)
Yeah. I'm not a fan of C++, though the compiler spends so little time running that this shouldn't pose much of a problem with bloat and clunk. On the other hand, loading C++ stuff is an abomination that takes eternity due to massive mangling (a problem Michael Meeks has spent a lot of time trying to marginalize with Bdirect linking, faster hash algorithms, etc), and the compiler gets run repeatedly.
I'm not sure mangling is really as much of a problem people make it out to be. It *did* cause problems trying to mix binaries from different compilers but I don't think it was ever really a performance problem. If linking is slower it's because the programs are larger.
OTOH name mangling is a massive benefit to programmers. Writing big programs is a huge pain in the butt if every single function/variable has to have a unique name. Namespaces are one of the reasons C++ programs scale so much better then C programs.
An observation of "procedural" coders (Score:4, Interesting)
I've never understood the hostility towards OOP. I've always seen it as nothing more than another great tool to use, but so many posters act as if OOP is some false god brainwashing the masses. My theory is they're taking the act of embracing OOP as synonymous with insulting C.
Look at the added java.io.PrintStream.printf() [oracle.com] method that uses a variable argument list. Someone had to be a special kind of asshole to adulterate a strongly-typed OO-language with that bullshit when the obvious OO solution is an array for a second argument. That's the kind of modification made when someone is making a political point, not a design improvement.
Re: progress (Score:4, Interesting)
The third party libraries for it are pretty nice these days, too. I'd rather do threading in C++ with boost::thread than in Java. I've found boost::regex and boost::program_options to be a joy to work with as well. Eigen is also very nice if you need a math library.
Overall I've been quite enjoying working with it. It's not nearly as intimidating as it first appears, and the stuff you really need to know about it is pretty simple and easy to learn.
STL... meh (Score:2, Interesting)
STL is ugly. Even the Qt framework provides a much cleaner and consistent alternative, than this "standard" library.
STL is also not good for any performance bound programs, not good at all. You can easily write code that looks nice, but silently kills your performance.
Re:too bad GCC is not relevant anymore thanks to L (Score:2, Interesting)
apparently the gcc code base is a complete mess as far as integration with other tools is concerned
Lots of that was self-inflicted. GCC maintainers did not permit attempts to refactor GCC into smaller reusable component libraries, or import / export abstract syntax tree (AST) data. Granted, these things were difficult due to GCC's legacy codebase problems, but you couldn't even try. Your patches would be rejected.
It was pure Richard Stallman tinfoil hat paranoia. RMS believes that if you make GCC too modular, especially with interfaces that can't propagate GPL virality, it will inevitably become a wedge used to destroy GCC. You see, people could then write non-free programs to extend GCC in useful ways. And under RMS-ism, you can't have that. It's better for holy free software purists to live in hair shirts than to permit changes which might theoretically allow outsiders to tempt them with evil. So RMS used his influence with the FSF and GCC to block attempts to move GCC in that direction.
There was also a lot of provincialism. I believe C++ used to be unthinkable, but that tune may have changed due to the success of clang / LLVM, which use C++ features to good effect. GCC's ancient crufty internals have become a huge barrier to progress, and this sounds a bit like belated recognition of it. (They have to be worried about contributor mindshare going to LLVM family projects merely because they're so much easier to work on.)
Clang/LLVM is financed by Apple and it is released under an Open Source licence. Call that parasitic if you like but because of Apple (in part) you now have a clean modern compiler toolchain that's a credible open source alternative to gcc. If nothing else, it means that the gcc dev team now have an incentive to improve their product because they have competition.
Apple was very frustrated with the state of affairs I described above. They (and many other non-purist GCC contributors from the commercial sector) wanted to modernize GCC to make it more competitive with closed source compilers, but the FSF literally wouldn't let them. See also: the egcs fork, which also had its origins in FSF small-mindedness. However, after egcs effectively won that battle, the FSF was able to bring GCC back under its control. If Apple ever considered a serious attempt to fork GCC, no doubt that outcome played a role in deciding against it.
Ironically, the result is that now we have a complete, high quality alternative to GCC, it's not burdened by a horrible internal design preserved in amber by misguided distrust of outsiders, it's licensed more permissively, it's structured exactly the way RMS feared, it's not rigidly controlled by the FSF (which requires that everything contributed to GCC have copyright assigned to the FSF), deep-pocketed commercial GCC contributors are migrating to it because it's run by sane people, and nobody is using it to force proprietary software on the free software community.