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."
If they used an early enough variant of C++, they would be relatively straightforward, since that has already been done once (cfront), but templates would probably make things somewhat harder, and would probably require a decent macro language. If they want some of teh nicer-sounding features of C++0a, things might start getting very horrible quite quickly.
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.
Why, exactly, is using STL a greater good from a compiler side?
For example, a std::vector may become correct more quickly than a home-grown array list because more eyeballs will be looking at it. In addition, its operator [] can be overloaded to provide bounds checking.
Since this is Troll Tuesday I'll be blunt - that's absolute horsheshit!
In testing, performance can be 4x SLOWER with the stl than by using c99. Variable-length arrays combined with bsearch make for one of the fastest look-up "containers" going - way faster than any stl algorithm.
c++ has its uses. It has nice features. The stl, on the other hand, is visually offensive. I bought the hardcover TR1 spec, read it twice, and consider it a waste of time and money. For what most people need, if they can't write their own classes, there's enough generic code that they can modify to achieve their goals.
On top of which, object-oriented programming is a paradigm, not a language feature. You can do OOP in c just fine by passing an explicit "this" as the first parameter in any function you want to act like a method call. You can even do OOP in assembler - Borland had some nice material on that.
Use c++ for encapsulation, for references, for the syntactic sugar - but not because the stl will make it run faster - it won't.
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.
variable-length arrays were a surprise to me too. I had been looking for the quickest way to do an in-memory search to find keys so I could look up the associated pointer, and as we all know, c doesn't have variable-length arrays ... but c99 does. Use -std=c99 on the compiler line.
What this means is that you can treat your chunk of ram as contiguous, and realloc to grow it, and if you try to do an array access past the "old" bound, you no longer throw an exception. So your initial array allocation (in my case, 1024 elements) could grown (again, in my case, to a million) and still work.
Doing a bsearch on that is dirt quick. Being able to refer to any element, even those beyond the original length, using standard array notation, is just SO nice.
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/variable_length_arrays.htm
Now don't tell me that isn't sweet! For some algorithms, it's a real game-changer, making them so much simpler to implement - and explain to others - that you never want to go back.
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.
how true
I had this funny 'aha' moment doing some simple operations on all elements of an int array: using a stl::vector and an iterator is actually faster than a plain-c int-array indexed by the loop-counter. The stl version boils down to pure pointer arithmetics, while the c version has the indexing overhead. Sure you can do the equivalent in c (as fast as an stl iterator, surprise, surprise), but honestly I like to keep away from this kind of stuff, most of the time.