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.
Re:too bad GCC is not relevant anymore thanks to L (Score:5, Informative)
Irrelevant? Not quite. For your particular use, maybe. But most Linux distros are still built using GCC, and most embedded platforms provide a GCC-based toolchain. So if, by 'irrelevant', you actually mean, 'the compiler with the most-often executed output code on earth', then yes, I guess you're right.
Re:too bad GCC is not relevant anymore thanks to L (Score:5, Informative)
No, no it does not mean anything of the sort.
Re:too bad GCC is not relevant anymore thanks to L (Score:5, Informative)
No, it means when you go in and add extra functions to GCC that those would have to be GPLv3 as well, at least if you want to distribute them.
It has NO effect on what the use of the application. In fact that is has no effect on the end user is one of the topmost clause of the GPLs.
More like "C with Classes" (Score:5, Informative)
I've read their guidelines, and they're doing much like I've been doing recently with moving from C to C++ for embedded systems programming, which is to avoid the really crazy shit that you can do in C++. In particular, exceptions and RTTI are absolutely verboten. They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source. Any templates outside of STL are also forbidden ("template hell" sucks), and I won't even use STL myself because I can't count on having a heap. Even iostreams are being frowned on except maybe possibly in debug dump code where no text language translations are needed.
C++ can really tidy up C code that uses any sort of function pointer hooks or object dispatch style switch statements with virtual methods. A class can become a mini-API, and even used as a sort of device-driver, as in the mbed [mbed.org] libraries. Doing this has really helped improve encapsulation in my own code.
Re:Classes/Templates are not a magic bullet ... (Score:4, Informative)
Re:Classes/Templates are not a magic bullet ... (Score:5, Informative)
Given a collection of developers that write difficult to understand, difficult to maintain and sloppy type unsafe code, going to C++ may not help.
It is very difficult to write easy to understand, type-safe, code in C.
The reason being that C requires so much micro-management that you end up with the code for that mixed in with the actual interesting algorithms. C++ basically makes the compiler do an awful lot of what you have to do in C anyway and does it for you automatically while keeping the details neatly out of the way.
It's also very hard to write type safe code properly in C. Just look at the classic example of the unsafe qsort versus the safer and faster std::sort.
I'd also be more optimistic if by using classes and templates they were really referring to using STL, not writing their own.
What on earth is wrong with writing your own classes and templates? They almost certainly already have a healthy collection of structs with function pointers and macros (linux certainly does have poor reimplementations of half of C++ using macros). These are best replaced with classes and templates on the whole.
That's the point. C++ formalises what everyone was doing in C anyway, making it much more uniform, easier to read, shorter and therefore much less prone to bugs.
Re:too bad GCC is not relevant anymore thanks to L (Score:3, Informative)
Re:More like "C with Classes" (Score:5, Informative)
Ignoring RTTI is fine, but forbidding exceptions requires a dangerous sort of doublethink. The language itself, as well as the STL, is defined to generate and use exceptions. By ignoring their existence, you banish yourself to a nonstandard purgatory.
For example, every new now must become new(std::nothrow). For every STL container type, you have to provide a custom allocator that doesn't throw. That's a bit unwieldy.
By denying exceptions, you force everyone to use error-prone idioms. For example, the only way a constructor can signal a failure is to throw an exception. If you forbid exceptions, then all constructors must always be failure-proof. And then you have to provide an extra initializer method to do the real initialization that can fail. Every user of the class must reliably call the init method after construction, which gets cumbersome when classes are nested or when you're putting instances into an STL container. It also means that objects can have a zombie state--that period of time between construction and initialization. Zombie states add complexity and create an explosion in the number of test cases. Separate initialization means you can't always use const when you should.
Exceptions are necessary to the C++ promise that your object will be fully constructed and later destructed, or it will not be constructed at all. This is the basis of the RAII pattern, which just happens to be the best pattern yet devised for resource management. Without RAII, you will almost certainly have leaks. Worse, you won't be able to write exception-safe code, so you are essentially closing the door to ever using exceptions.
Re:too bad GCC is not relevant anymore thanks to L (Score:2, Informative)
LLVM was created by freeBSD due to the continual dropping of support for older hardware by the GCC team.
Wrong! [wikipedia.org]
The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages.
Re: progress (Score:4, Informative)
Re:C++? (Score:4, Informative)
C++? seriously?
That's it, I'm switching to LLVM!
which is also written in C++
Re:RTFA (Score:4, Informative)
Bootstrapping on another platform is done as follows:
Note that at no point does the target platform need some other way to compile gcc independently in order for the port to happen.
Re:too bad GCC is not relevant anymore thanks to L (Score:5, Informative)
The GPL doesn't force you to give back. You need to have a read of it, it only forces you to "give forward".
Apple has now fully embraced clang/llvm for a couple of reasons: it was legally very difficult to for them to integrate gcc tightly with their IDE (by which I mean they would have to GPL Xcode if they linked directly to gcc); it is technically very difficult to integrate with an IDE - apparently the gcc code base is a complete mess as far as integration with other tools is concerned.
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.
Re:libgcc and libsupc++ (Score:4, Informative)
Were it not for the exception, anything compiled with the [gcc compiler?] would either be GPL (because of libgcc and libsupc++) or produce a linker error (because the libraries are called and not present).
I think you mean "linked with libgcc/libsupc++". One can compile code with gcc/g++ without linking against the bundled libgcc. For example, the BSD-licensed libcompiler-rt library produced for the LLVM project is said to be a drop-in replacement for libgcc, and as a bonus, it's even a bit more efficient. If the same is not already true for libsupc++, I'm sure it's only a matter of time.
Re:too bad GCC is not relevant anymore thanks to L (Score:4, Informative)
And the AVR I have used used a mix of GCC and GNU assembler. I think someone somewhere had an official commercial compiler for it but that doesn't help if it's not licensed for anyone in the company to use.
I have actually seen cases where companies license one commercial compiler for use in production builds while all the developers use GCC, out of concerns that the commercial compiler is more efficient while being too expensive to license more broadly. Over time there's pressure to dump the commercial compiler because it tends to be difficult to debug when the devs don't have access to the production compoiler, and because it turns out the expensive compiler doesn't really generate more efficient code.
Re:bad_alloc (Score:4, Informative)
It could be worse though, in .NET if you run out of stack, you don't even get the exception - it just exits.
You do get a StackOverflowException [microsoft.com], actually. The catch - pardon the pun - is that it's a "magic" exception type that cannot be caught by user code, since .NET 2.0. So in practice it's only there for debuggers.
Re:GCC should remain small and fast (Score:4, Informative)
Doesn't help. STL arrays are allocated on the heap, and that's a quite slower and more wasteful allocation form than on the stack.
What is an "STL array"? If you mean std::array, then no, it's allocated on the stack. If you mean std::vector, then that's a dynamically resizable array, and an analogous data structure written in C would still be heap-allocated - you'd just have to do malloc/realloc/free yourself.
Sure, you can use C arrays, but guess what: out go type safety and STL algorithms and C++ idioms.
Again, wrong. Since raw pointers are iterators, you can perfectly well use STL algorithms and other C++ idioms with C arrays. In C++11 it's even easier now that std::begin and std::end are defined as global functions, and overloaded for arrays, so you don't need to much around with pointers at all. Type safety is still there as well, since C arrays are typed.