GCC Moving To Use C++ Instead of C 546
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."
Seems odd... (Score:3, Interesting)
I'm guessing that only the C++ compiler part will be written in C++. Sort of an Ouroborus.
One of the reasons for gcc being in C for so many years is that it was easier to get a bootstrap c compiler running on a given platform to compile the full gcc toolchain, but I would guess that a C++ compiler was not that important to those people anyways, but it still begs the question.. how do you get a C++ compiler working on a platform that doesn't have one?
Re:C++? (Score:1, Interesting)
Linus will raise! (Score:1, Interesting)
considering he sustained that C++ is utter crap and that is why he didn't use it to develop git.... I just long for his rants... ^_^
Re:From the article it is obvious (Score:2, Interesting)
Finally! (Score:2, Interesting)
For this kind of job, C++ really is better than C. One of C++'s goals was to standardise things people were doing in C anyway (eg OOP). The advantage of C++ is that the compiler writes all the boilerplate for you. Not only that, but it does it right every single time. Every line of code you don't write is one that does not have a bug.
The main problem is that it is easy to write a basic C compiler and thereby bootstrap a system. With GCC's cross-compiler abilities, this is less of a problem than it might otherwise be, since bootstrapping can always be done on an exitsing, supported platform.
The other solution is for the GCC developers to open up the middle end (like LLVM has done). This would allow one to relatively easily target the compiler to output C, and even a very simple subset thereof, making the bootstrapping process easy. I appreciate their reasons for not wanting to make this easy: they want to prevent proprietary front ends making a mockery of the GPL. I personally think that in this case, they have gone in the wrong direction, and opening up the middle end would yield far more open, copyleft compiler front ends.
Kind of like FUSE has done for filesystems. Sure, it is easier to write a proprietary filesystem than it has ever been for linux. But it is also vastly easier to write free ones too. The end result is that there are far more Free (tm) and interesting filesystems than there ever were.
So, I think in this case that by making lift harder for developers, they have done a bit more damage than would have been caused by accidently making life easier for proprietary developers.
But, that's my $0.02. And I'll keep supporting GCC, not LLVM because it is GPL. I don't want to see the return of the bad old days of code full of #defines written to work around missing features and bugs in 100 different, bad vendor compilers.
Maybe they've grown up a bit (Score:3, Interesting)
Maybe they've admitted that 'pride' is holding them back and that being able to use STL (for example) is a greater good than being able to do an initial compile on some obscure microcontroller which has a barely functioning C compiler.
Re:Safe subset (Score:3, Interesting)
On the other hand ... having the compiler mangle the names for you instead of having to do it manually "MyClassAddFloatAndInt()" might be a win in the long term.
Re:Seems odd... (Score:4, Interesting)
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.
Re:Choices, choices (Score:5, Interesting)
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.
Hooray for a slower compiler! (Score:3, Interesting)
Re:Maybe they've grown up a bit (Score:5, Interesting)
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.
Re:From the article it is obvious (Score:1, Interesting)
Informative? More like troll. Objective-C didn't include Garbage Collection until 2.0, just released. And GC isn't part of the language anyways it is just an implementation detail of their provided base NSObject. My ObjC runtime for embedded systems uses a very different base object implementation which sacrifices some(but not all as using C++ would) dynamic features for speed and memory savings.
I have never met an OO problem that cannot be solved in C. Objective-C makes it easier. C++ just creates more problems.
Objective-C is fast to compile, simple, 105% C-compatible. IMO, Objective-C should become C1x.
More eyeballs (Score:4, Interesting)
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.
Re:Choices, choices (Score:3, Interesting)
Speaking of "syntactic sugar", this link below is a good one. Someone above linked to it. I'll just add a little bit to it here. A reference is a pointer, and anyone who tries to tell you otherwise is a fool. It is there to make things more readable - it is not a copy of an object, and the simplest of exercises in the worst book I've read on the language make that very clear. So I don't know why people think they are anything other than fancy pointers.
And they aren't talking about using the headache inducing C++ code, they are going to use the advantages of C++ to make the code simpler and cleaner. At least according to this guy, and if everyone ignores this guy then it's time to fork it and keep it C. I've been using C for 15 years and C++ with STL for 12 at least, and it is natural for me to use straight C with a few C++ features. I always use 'new' instead of 'malloc' because it's harder to screw up the size calculation. Any time I use memory allocation, I use smart pointers - I don't hack them on later.
And if there is some corollary function call that has to be made with another function call, you have a few options. If one has to be called first all the time, why keep them separate? Well of course it keeps the code clean and simple, and it's harder to introduce bugs in initialize-and-use functions. So you keep both of the functions, most easily as Private members of the class, and then you implement the common usage pattern "initialize and use". Set/Get operators are the same way - the code just sets a property, and doesn't care about all of the activity that's triggered behind the scenes.
They aren't trying to make this a headache, they are trying to make the code simpler. If you let it, C++ keeps you from making the same mistakes that C is ridiculed for such as poor memory management. You can cause other side effects if you use everything the language has, but as someone else explained above, few people have gone through the trouble of learning all of the more arcane features of C++ so it's unlikely. More likely is, someone puts in a crazy overload somewhere and someone else rejects the patch saying it doesn't make sense to do it that way, simple is better.
http://gcc.gnu.org/ml/gcc/2010-05/msg00757.html [gnu.org]
Re:Maybe they've grown up a bit (Score:1, Interesting)
Why, exactly, is using STL a greater good from a compiler side?
Same as for any other large programming project: It makes it easier to write and maintain.
bootstrapping... (Score:1, Interesting)
ah so many of you don't remember the REALLY early days of linux and having to bootstrap gcc. I don't even really recall the details any longer other than IIRC it took 3 full code compiles which took what felt like forever on old 386 machines with a couple meg of RAM... then building X11 which took about as long. ...then the distros with 20 or 30 floppy images appeared with binary packages... no more hours of waiting to build gcc and X11.
Anyways if you read the email link, you'd see they really only want bits and pieces of C++ since, apparently, most of their contributors aren't familiar with C++. Also if you follow the thread they're still obviously in the very early stages as they're branching out into also of unrelated/unimportant/pedantic nonsense interspersed with healthy doses of common sense.
Re:welcome to 1985! (Score:3, Interesting)
We switched to using C++ for our applications in 1996, more because of the need for GUI integration than because the language did anything magical for our algorithms.
Oh, and at that time, we suffered about a 50% performance hit, even with "cleaning up" our algorithms moving from a 6 year old unplanned C code base to a freshly planned C++ structure. The performance hit was more or less irrelevant, the old code (had a GUI, but) ran in DOS, the new code ran native in Win95, we needed to be in Win95 - resistance was futile.
I think the gcc can benefit from STL containers and such, not that they don't have solutions for all that already coded in C, but switching to the standard ones will make things a bit easier for non gcc veterans to grok, and they should benefit from massive parallelization more easily if they are using standard libraries instead of retooling their old code base for it.
Re:Maybe they've grown up a bit (Score:3, Interesting)
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.
Re:Maybe they've grown up a bit (Score:2, Interesting)
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.
Care to elaborate on this? I'm a c++-guy, and these VLAs tickle my curiosity. Any idea on what makes the performance difference between the STL algorithms/containers and VLAs? If it's heap allocation, that can be worked around in several ways, but if it's something else well then things just got interesting.
Re:Maybe they've grown up a bit (Score:5, Interesting)
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.
Re:Maybe they've grown up a bit (Score:4, Interesting)
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 [ibm.com]
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.
Re:Maybe they've grown up a bit (Score:5, Interesting)
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.
Re:Maybe they've grown up a bit (Score:2, Interesting)
Parent doesn't know what he's talking about.
In C++ you can have std::vector with std::binary_search, which will be at least as fast as bsearch. The reason -- bsearch calls a comparison function for each stage of the search, but std::binary_search, being a template, can inline the comparison.
But anyway, normally you wouldn't use them, because such a combination is essentially the same as an overly complicated std::set. The difference is the dynamic allocation, but if it bothers you, you can always give it your own array allocator. And if, for some strange reason, you want to refer to inexistent indexes, std::map::operator[] will allow you to do that, and create a default value under that index when you first access it.
The STL is convenient, flexible, fast and there is no way anything in C can live up to it.
Re:Maybe they've grown up a bit (Score:3, Interesting)
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.
Re:Seems odd... (Score:1, Interesting)
I used to share this sentiment. And then I met their majority C equivalent, the same people who only know C but cannot program in C either.
So I think what you meant to say is, C++ programmers who don't know resulting assembly generation for a particular compiler. Most C++ programmers working in performance critical areas can give you a good approximation of any particular segment of code. C programmers are no more optimization experts than their C++ counterparts, just on average due to C's much lower learning curve.