Slashdot Mirror
GCC Moving To Use C++ Instead of C
An anonymous reader writes "CodeSourcery's Mark Mitchell wrote to the GCC mailing list yesterday reporting that 'the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake.' Still undecided is what subset of C++ to use, as many contributors are experts in C, but novices in C++; there is a call for a volunteer to develop the C++ coding standards."
I spent a lot of years developing in C, some time in C++ (w/o using the standard template library) and the last year and a half using C++ with stl. So I think I have a pretty valid basis for comparison, and I'd say that C++ has far more ways to go wrong than C does. With C, you pretty much know what you've got. C++ has a number of subtle, nasty bear traps that can bite you. It's true that if you know what you are doing, you can produce good code & get the job done, but that's true of any language, including assembler.
... The operators < and > were tried, but the meanings "less than" and "greater than" were so firmly implanted in people's minds that the new I/O statements were for all practical purposes unreadable."
Here's a couple of items off the top of my head:
Default assignment operator: All you need to do is add a pointer to your class and suddenly code that you don't see causes a bug. Yes, IF you know about this you can work around it. That's true of anything.
Overloaded operators: I was leafing through the original Stroustrup C++ book and found this paragraph about the stream output operator '<<':
"But why <<?
Well, yes, when people see an operator, they "think" they know what it's doing. It's interesting to me that in this very first case of overloading, Stroustrup ran into this fundamental problem, and had to choose a somewhat obscure operator to get around it.
References: references aren't what most people think of as references. They are pointers with syntactic sugar. Try getting a reference to an element of a vector, and then doing something that causes the vector storage to be reallocation. Voila, you have a "reference" that refers to junk.
All of these aren't impossible problems. They are extra issues, inherent in the language, that you simply don't have in C. I think that C++ has a lot of interesting ideas, it has a lot of power, but ultimately it also has a LOT of problems.
It's not like using STL makes code faster or less memory hungry
Sometimes it does. For example, compare the stl sort routine with qsort. The stl version is declared with a predicate method that can be made inline. The C version is passed a pointer to a predicate function that can't be inlined. So, the C++ version can eliminate a function call with each compare.
But this is library and compiler dependent. In theory you really need to know how your compiler and library perform. In practice, it's so mature that everybody is pretty fast these days.
Oddly enough, STL contains a bsearch algorithm that works on variable length arrays and generates code which is pretty damn optimal. It also contains a highly optimized quicksort implementation (along with other sorting and inserting algorithms) that you can use to keep your array sorted. However, even the standard vector operations compile down to pretty much raw pointers if you use iterators, so you can use quicksort/bsearch with no extra penalty on a vector and all the work is done for you.
So it sounds awfully what you're saying is absolute horse-shit.
I've not only tested it, I've looked at the disassembly of output that various C++ compilers produce from STL code at maximum optimization settings. In pretty much all cases, the algorithms are very aggressively inlined, with the overhead non-existing. I.e. you'd not do any better by manually implementing a sort or a binary search inline at the same point.
STL containers are somewhat slower when excessive copying is taking place. This was hard to avoid in the past in some cases - you could use std::swap to optimize manually, but it was not always possible. But C++0x has rvalue references and move semantics now to deal with this, and STL containers use them to greatly optimize things. Furthermore, rvalue references enable perfect forwarding, and that, combined with typesafe vararg functions built on template parameter packs allow C++0x STL containers to provide member functions to instantiate objects directly in-place, without any copying (emplace_back etc).
And g++ already implements all this, so it's immediately applicable here.