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."
how do you get a C++ compiler working on a platform that doesn't have one
Why not bootstrap using a cross compiler?
The headline says "Use C++ instead of C" which is incorrect. C++ is, as made obvious from the text, an option, not a requirement.
Are they seriously trying to suggest that the people who work on developing and maintaining a C++ compiler are novices in C++??
Sorry , am I missing something here?
Here's somme ammo from bash.org:
In Soviet Russia, our new overlords are belong to all your base.
The GCC guys are not going crazy here. They are discussing what subset of C++ to allow.
If you use all the wild features of C++, the results could be scary. For example, operator overloading is great if used judiciously, but if used badly it can make the code a mess. And if it is used at all, then it means that you can't look at one page from a printout and know for sure what that code does; you need to look at all the class functions to make sure there aren't tricky overloaded operators.
I use plain C all the time at work, and the top C++ feature they should be using is simply the object-oriented class stuff. With a single global namespace you need to make functions like MyClassAddFloatAndInt(), but in C++ you could just call that function add(); it would be part of MyClass, and if you have other "add" functions with other type signatures, they won't collide. They could go from:
{
MyClass m;
MyClassInitialize(&m, foo, bar);
MyClassAddFloatAndInt(&m, 3.0f, 2);
MyClassDoSomething(&m);
MyClassCleanup(&m);
}
to:
{
MyClass m(foo, bar);
m.add(3.0f, 2);
m.do_something();
}
Even better if they allow the use of C++ namespaces to keep a large project organized.
The other major win that comes to mind is simply being able to use powerful C++ libraries like the STL. Not having to cook up some kind of container data structure in plain C, but being able to use std::vector<SomeType> and std::map<SomeType, OtherType> and such is a huge win.
P.S. I read through much of the discussion and here was my favorite post:
http://gcc.gnu.org/ml/gcc/2010-05/msg00757.html
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
now I'd like to see the graph of what was used to compile each compiler, until the first one written at hand on perforated cards, programmed for abacus in the classical ages
Quis compilabit ipsos compilatores?
ecco, tibi fixi .
The C++ FQA is mostly a bunch of rhetoric and sophistry with a good scattering of half-truths thrown in for good measure. It is a classic propaganda piece as the falsehoods are spread very continuously spread and mixed with truthful pieces. That makes it hard to debunk in a short post as one has to go in to nit-picking detail in order to expose it for the hokum that it really is. Fortunately, you can use your favourite search engine to search tha annals of comp.langg.c++.moderated for such information.
SJW n. One who posts facts.
That and the fact that C++ operates on a higher level of abstraction and therefore requires much more careful consideration and planning.
Planning... so you plan, then write, and you are done? This is a project that is expected to live for decades. The requirements change.
If you need more planning, that's a bad sign.
The problems I have seen in the past have all been centered around people not quite understanding the nature of C++ and wanting to immediately put all those bright new features to "good" use, by overloading everything and indiscriminately inheriting from any number of classes.
Yes. Expect it to happen, despite any efforts to resist. This is the nature of a project with more than one developer.
The secret to good programming has always been to keep it simple - this is twice as important in C++, and the language has some great features for doing so, but you really have to understand what it is you are trying to achieve.
Human brains are not SMP hardware. A group of people working together will not all see the same big picture.
Nobody on Earth fully understands all of C++. Every C++ programmer knows a subset. My subset is not your subset; it is unique to me as yours is to you. Features I love make you uneasy at best, and your pet features do likewise for me.
The features sneak in here and there... well I just can't resist because I really NEED my favorite feature! Think of the classic 2-circle Venn diagram for two people's C++ knowledge: you might hope for your project to be that intersection in the middle, but it's going to end up with the big fat union of pet features.
Really, you can't stop it. Resistance is futile.
You'll see exceptions, then memory leaks, an attempt to solve it with some kind of braindead "smart" pointer, somebody needs multiple inheritance, some ass overloads the comma operator or () operator, overloading gets sort of ambiguous with differences between the 32-bit and 64-bit builds, Boost gets pulled in with compile times and start-up times going to Hell, people cry for Java-style garbage collection...
Yeah, exactly. I don't understand why they didn't chose something modern like Ajax.
Mada mada dane.
grep MyClassAddFloatAndInt *.c
grep add *.c
This totally sucks. Now I need some complicated language-specific search tool that is sure to have fewer options than grep. It's probably not even scriptable, and surely much slower. Why do you want me to suffer?
With the nodes that insert a backdoor into the unix login program colored red.
It was Flow-Matic aka B-0 which later kind of evolved into COBOL, also designed by her.
My other account has a 3-digit UID.
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.
Quite simply because STL is the embodiment of several decades of algorithms and data structures research work. In many cases, use of STL results in near optimal code. In raw C, you're left to yourself to write your own collections and algorithms. You have to try pretty hard to surpass the performance of STL. Do you want compiler developers to constantly reinventing wheels or actually improving the compiler?
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.
The English language, being the whore that it is, pretty much allows you to make any word or phrase mean anything over time, as long as you use the generally accepted meaning at the time.
For all intensive purposes, I could care less.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.