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?
It's not a horrible language if you take into account it's requirements. C++'s requirements are horrible and make it the monster it is. It has to have all the low-levelness of C with all the high level goodness of a modern OO language. Languages like Java, C#, Ruby, etc.. all have the advantage of not having to be a low-level language as well. While OS's have been written in languages like Pascal (original MacOS for instance and early versions of Windows) those were also largely custom compilers that added low-level functionality to the language.
So basically, C and C++ are unique in that they are required to be systems languages as well as applications languages. This makes both of them quirky to say the least.
If you need web hosting, you could do worse than here
Enjoy
Great idea! This will surely help steal back users from LLVM/clang. The reason people are jumping ship is because they want a compiler written in C++, it has nothing to do with performance, licenses and/or features. Just thinking about those crunchy templates, page up and page down, makes my mouth water. I can't even begin to comprehend how they ever got anything done without templates.
To paraphrase Einstein:
Make things as simple as possible, but not simpler.
IMHO, one should use as high level language as possible, but not higher. One should never choose a lower level language than necessary only because it is hard core, the choice has to be based on something more substantial.
I've met several C programmers having the knee-jerk reaction when they hear the word C++ that it's bloated and slow and hard. And tell me what, they haven't read Stroustrup's FAQ lately. C++ can be very lean and mean indeed. As can C# (which I'm mostly using right now).
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?
C++'s requirements are horrible and make it the monster it is
I don't think you are right there. I used to be very sceptical about C++, but I have had to develop some tools with it recently, and my respect for it has grown a good deal.
It is true that C++ programs can be real horrors to maintain and even to write, but I think the problem often lies with the design of the toolset used. That and the fact that C++ operates on a higher level of abstraction and therefore requires much more careful consideration and planning. 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.
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.
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 .
Because ObjectiveC is a slow shit?
Seriously, it might be OK for designing GUI interfaces, its dynamic nature helps there. But for compiler writing I'd prefer something:
1) Fast.
2) Typed.
3) Deterministic (no non-deterministic GC).
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?
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.
With the nodes that insert a backdoor into the unix login program colored red.
Why, exactly, is using STL a greater good from a compiler side?
For a C++ user, sure, but the compiler gains nothing from this, AFAICT.
It's not like using STL makes code faster or less memory hungry, which, second to the algorithms, should be the focus.
If I were to guess, allowing C++ serves one real purpose: bringing in the large amount of programmers out there that work with C++. Not because their running code is superior, but because they are there.
At best, the compiler would date back to Grace Hopper, as she was the person who invented the compiler. I believe it was for Fortran.
Learn something new.
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.
Pride?
Come on now, let's be fair. They said that boot strapping with only C was the reasoning. If you've ever bootstrapped a compiler or even worked on cross compiling tool chains for a new platform, what they did is huge. There is a reason that GCC is the compiler just about everywhere. you don't have to like it and I'll agree that some of the reuse stuff C++ can provide is potentially huge but it's not pride, it's the desire to be useful.
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?
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.
Nope, not a troll.
Objective-C is poor. For example, the most useful part of C++ are fast typed template containers.
Objective-C has only pointer containers which are untyped.
'Const' support? Nope.
RAII and smart pointers? Nope. Memory management in Objective-C is quite convoluted, btw.
So almost nothing useful for general-purpose programming. Except maybe for inheritance.
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.
c++ programmers who don't know c all that well (and there are LOTS of them - maybe even the majority) are not the best.
Or even from the GCC build instructions:
- Michael T. Babcock (Yes, I blog)
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.
Crappy programmers are crappy whether they lean on the STL or not. Their implementation of pre-existing STL containers and algorithms is bound to be terrible.
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.
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.
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.
This is a compiler we are talking about. I think that we can assume that people who program the program that turns code into machine code must "know their shit", so to say - otherwise the time taken to compile will be the least of the user's problems.
Besides, having people copy code from a webpage/programming manual doesn't improve things any.
No, they simply memorize magical mantras that, when regurgitated, will do what they want. It's much better to give such people as high-level libraries as possible and let them use those; the more they have to think about optimization, the more likely they are to do something unbelievably stupid.
Besides, the exact same argument could be used to condemn first OO, then structural programming, then anything that gets compiled, then finally machine code itself as an abstraction over the physical hardware of modern processors.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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.