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."

Comments

Re:Choices, choices

[murdocj]

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.

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 <<? ... 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."

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.

Re:Maybe they've grown up a bit

[XDirtypunkX]

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.