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."
I think it's a sign of impending apocalypse (Score:2, Insightful)
Either that, or could we be about to see the beginning of a gcc/llvm compiler arms race?
Re:Seems odd... (Score:5, Insightful)
how do you get a C++ compiler working on a platform that doesn't have one
Why not bootstrap using a cross compiler?
Re:C++? (Score:4, Insightful)
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.
Re:What... (Score:3, Insightful)
Well, ever thought that issue also happened for a gcc written in C? Compilers come with minimal bootstrap compilers written in assembler to initiate the first compilation. Then compilers compile themselves several times until they reach a final version.
Re:C++? (Score:2, Insightful)
Oh, it's got its pros and cons, just like any language. At least with C++, you can point at any given piece of the language, and whether or not you like that piece, understand why it was designed that way. At least with C++, there are rational explanations for why it is the way it is. If C++ is the worst thing you've ever used then I strongly suggest trying to do something nontrivial in AppleScript; C++ will seem pretty awesome after that. :)
Choices, choices (Score:4, Insightful)
To paraphrase Einstein [wikiquote.org]:
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 [att.com] lately. C++ can be very lean and mean indeed. As can C# (which I'm mostly using right now).
Re:Seems odd... (Score:3, Insightful)
Thinking even harder ... they could compile GCC on another machine but set the output target as the platform they're trying to get it to run on. Then you just copy the binary across.
Re:C++? (Score:1, Insightful)
I would call the "high level" part a goodness. It's overly complex, making it too complex to understand, and hard to read and write code. C is already hard, but this is because of the low level part which you can't go without, and C++ just makes it insane.
And some language decisions are troubling. Abusing left and write shift with streams? I nearly puke when I see code like that. Couldn't they just have a 'write' and 'read' methods? It's confusing as to whether the code is doing shifts, or writes, or what, making it hard to read.
Template metaprogramming? Macros were already a way to make everything horrible, now there are even more things that allow you to do this. While it is a useful feature, any template code is nearly incomprehensible.
References for me are just more complicated pointers that only make code even harder to understand. And if you're doing high-level OO programming you should be avoiding using such constructs, just pass or return an object that carries the required information. Returning values through arguments like that is a bad idea, like all the things that references allow you to do. f(x) changing the value of x is a completely unexpected and surprising result for me. In C at least it had to be f(&x). Not to mention the use of & for references confuses the hell out of me.
Everything new, including the good things, like == overloading, and the way they are implementing, contributes to the extreme complication and insanity of C++.
C++ is the most horrible Object Oriented system you could add on top of C. Even Objective-C is better.
As everyone forgot EGCS vs GCC back in Linux 2.x (Score:0, Insightful)
Damn I remember how everyone was fighting with different versions of slightly different compilers. Kernels of Linux back in 2.0 and 2.2 were a mess, and I was maintaining Caldera OpenLinux distributions numbered 2.1 to 2.3 (those aren't Linux kernel versions, but box product revisions). Yeah, I was the sole user that Darl McBride prided himself on just because OpenLinux was specialized for the better IPX network share support that my Fortune 10k company needed. Thankyou PJ and Groklaw sandwitchcraft for the smoke and mirrors.
Re:C++? (Score:5, Insightful)
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.
Re:Choices, choices (Score:5, Insightful)
If you want to link to any FAQ, don't forget the FQA about C++ http://yosefk.com/c++fqa/ [yosefk.com]
Reading it will give you an inside on the many issues you can have with C++. I don't oppose C++, but You Have To Know What You Are Doing (TM). Or else all hell breaks lose. Fixing bad C is doable, fixing bad C++ is the 7th circle of hell.
Since they're clearly stealing ideas from clang... (Score:2, Insightful)
Maybe while they're at it, they can add in actually-useful error messages. See http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html [llvm.org] for some examples. It's shocking how user-hostile GCC is in comparison.
Safe subset (Score:5, Insightful)
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 [gnu.org]
steveha
Re:Choices, choices (Score:5, Insightful)
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.
thus a disaster (Score:5, Insightful)
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...
so now I can't grep for functions (Score:5, Insightful)
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?
C, the best sub set of C++ (Score:2, Insightful)
Subject line says it all. C is the best subset of C++ there is or ever will be.
Re:Finally! (Score:3, Insightful)
Wait, people were doing OOP in C? I didn't get the impression that all the compiler people wanted C++ for the OOP. Maybe all that some want are the little syntax shortcuts and cleanups and relaxations of rules, like '&' in function declarations for pass by reference, not having to typedef structs in order to refer to structs by their bare names, and ability to declare variables in the middle of code blocks, things like that. Maybe they want member functions and polymorphism only to have cleaner syntax for function pointers and not for actual polymorphism, so that if there was a way to do that without dragging in the full suite of OOP features, they'd go that route. They don't want exceptions. Maybe they don't want function overloading, templates, and operator overloading with the fun name mangling all that needs.
If so, what they should do is create a new standard for C. Call it "C1x". And I certainly wouldn't leave out things just for being new in C++0x as suggested in the article. Extended initializers is just the sort of thing that isn't necessarily OOP and could go into a new C standard. Add a few things too like a triple comparison operator to make a simultaneous comparison? Certainly fits with one of the big themes of C of being close to the architectures, and every architecture I've come across can do that, so why can't C do that?
Re:Maybe they've grown up a bit (Score:4, Insightful)
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.
Re:Finally! (Score:3, Insightful)
If you mention the possibility of some terrible corporation forking and making a proprietary version of the compiler, I'll be disappointed. That situation has no impact on the "schmuck".
By the way, have you ever looked into how difficult it is to actually contribute a bug fix back to GCC? It's such a hindrance (that's putting it mildly) that patches don't get contributed back. I've got quite a few that I could give back myself on GCC and binutils, but I'm not goign to spend 6 months of my time and my employers time (and approval) to jump through absurd and artificial hoops for an FSF project. LLVM does not suffer from this with their implied copyright assignment (and the fact they actually review bug reports and patches). GCC expects the patch provider to constantly ping the group 4-5 times until someone is so tired of the complaints that they actually review the code. Sorry, that's not acceptable.
Re:Choices, choices (Score:3, Insightful)
They have a few good points though. On the iostream vs printf issue, they're right that printing formatted output with iostream is stupidly verbose.
The following are indeed equivalent (actually, the stream version seems to be missing either "0x" or std::showbase)
printf("0x%08x\n", x);
std::cout std::hex std::setfill('0') std::setw(8) x std::dec std::endl;
I'd much prefer it if it was:
using namespace std;
cout fixwidth(hex(x), 8, '0') endl;
which is nearly as short as the printf line.
Re:thus a disaster (Score:1, Insightful)
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.
Well, if you think that planning is only necessary at the start of those decades ...
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.
Eventually? Quite likely. Immediately, as in the next two releases ? Just as likely no.
A group of people working together will not all see the same big picture.
And this differs how from the situation with the current machinery in GCC?
... in contrast to the current GTY(()) machinery already in GCC for the purpose of garbage collection?
tl;dr
GCC already has most of the problems you foresee because it is pushing the envelope of what is doable in "plain" C - and there are established processes to deal with that complexity.
Re:Virtual functions as mentioned in the link... (Score:3, Insightful)
Templates - how will they do STL without templates??? Seems like a big fail to me.
The only thing STL adds over traditional container libraries is generics. Why does a compiler need generic containers? The only container that isnt easy to implement-as-needed in the STL that I see a compiler needing (and only for efficiency reasons) is an associative array, and that doesnt actually have to be generic at all.
I would think that it would be far more preferable to (continue to) implement these things specifically for the compiler, and further that people who think that its hard probably shouldn't be involved in the GCC mainline. Perhaps a nice fork for the algorithmically-impaired is in order.
Re:Maybe they've grown up a bit (Score:3, Insightful)
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.
Re:Finally! (Score:2, Insightful)
I think the view in the GCC community is that eventually they'll use all of C++, just judiciously at first. If you look at GCC source code they're already doing many C++ concepts in C like single inheritance, vtables, etc. It's just that those things look like gross hacks in C and are error prone. For example, to have inheritance you have to maintain structs where the first few members are the same so you can cast between them. Having an enum for what type it is, and voila, there's dynamic_cast. Being compiler writers they know how to do all the tricks, it's just a pain to keep doing so when there's a language that formalized all those idioms already.
Not all that slow (Score:3, Insightful)
Objective-C isn't necessarily that slow. Message passing can be about four times slower than C++ method invocation, but once cached, the two are comparable. (SEE here [mikeash.com] for some interesting stats.)
In a system as IO-heavy as GCC, your bottlenecks probably won't be your method calls / message passing. And as for being deterministic: why would a compiler have to be deterministic? There are no hard real-time considerations for compilers. Your variation in compile-times will be minimal, even with a non-deterministic GC.
I think your point 2 (typed) is fairly valid. Part of the reason to move to C++ is to provide a language that is more strongly-typed than C. While the run-time binding of Objective-C makes it a great language for some applications, it does remove some compile-time type checking. (You do get warnings about an object type's ability to process a message, of course, so you don't lose it all.)
Re:From the article it is obvious (Score:5, Insightful)
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.
Re:Finally! (Score:2, Insightful)
I'm 33, been writing code daily since I was eight, I started doing C++ around 18, really bought into it, and finally gave up and moved on around 28. I've been there and done that. I've seen projects grind to a halt while people are busy painting their multi-paradigm bike sheds.
There is no anti-C++ dogma here, only sharing of hard won experience.
Re:so now I can't grep for functions (Score:1, Insightful)
That doesn't work. There's not such entry in the popup menu.
The popup menu reads:
Open Terminal
Open Tab
---
Close Tab
---
Copy
Paste
---
Change Profile >
Edit Current Profile
Show Menubar
---
Input Methods >
Of course, if your intent was that I should switch to some separate, low-quality environment where actually editing text is lousy but I get some odd menu item with right click, I can tell you that my experience from having tried that is that I lose more time than I gain. The net best situation is to run vim in one window to do the actual editing, and have the bad editing environment available for lookups. I've done a short trial of fully switching to those new-fangled "integrated development environments" - a year or so - but they just didn't work for me.
Re:Crap (Score:3, Insightful)
In all the years this has been debated (at least 15), I've yet to see a concrete example where C is faster than C++.
Not one.
If C++ was really slower or more bloated you'd think it would be easy to demonstrate, but nooooo. All you ever find is that the person on the other end doesn't know C++.
Re:Out of the ashes and into C++ (Score:1, Insightful)
Re:From the article it is obvious (Score:1, Insightful)
Obj-C is why Apple is running circles around MS and Google. Whether you love em or hate em, Apple innovates highly polished products the fastest. MS: stuck with C++ no real innovation in a decade. Google: Love some of their stuff, but they haven't really standardized on one language. A lot of Google's stuff is 1/2 finished as a result.
Dynamic typing is a very important enabler of tight code (closures for example). It also enables far beta meta programming like unit tests and build automation. Static typing is the problem, not the solution.
Of course this stuff flies over the heads of most business deciders, and also programmers who enjoy disentangling spaghetti instead of writing unit tests because it gives them job security! More Parmesan with that?
Re:Maybe they've grown up a bit (Score:3, Insightful)
But then, crappy programmers misuse them, not knowing about what is done behind their back, and it becomes slow and bloated code.
Having to specify everything explicitely makes you aware of the complexity/memory usage of what you are doing.
Re:Seems odd... (Score:4, Insightful)
c++ programmers who don't know c all that well (and there are LOTS of them - maybe even the majority) are not the best.
Re:so now I can't grep for functions (Score:1, Insightful)
Ummm... just right click the function name and select "Find all references" from the popup menu.
Popup menu?
You do realize that this is Unix and that quite a few people LIKE using the command line, with editors like emacs or vi, tools like grep and find and sed, with "plain" Makefiles and so on, right?
Not everybody uses a GUI IDE. For that matter, not everybody WANTS to use a GUI IDE.
Re:Choices, choices (Score:1, Insightful)
Here, here, my good man. I do exactly the same thing as you. C++ is great as an expanded C. I use it to simplify my code (yes, that's right) and to leverage the object features of C++. I keep to a minimum the use of the abstraction-y bits such as templates, inheritance chains, and overloading precisely because things can creep in that are hard to catch at a glance. I figure that if somebody can't look at an individual function / method and see exactly what is supposed to happen, then you've just created something that will never be properly peer reviewed. Nobody wants to have to work their way back through 6 super calls to determine what the given state of a member is or if '+' really means add in x = y + z.
Re:The devs don't know C++?? Its a C++ compiler! (Score:2, Insightful)
Learn the difference between isA and hasA relationships.
Re:Maybe they've grown up a bit (Score:4, Insightful)
Re:Seems odd... (Score:3, Insightful)
In the realm of symbolic languages (such as all natural ones), yes it does. The term "van dyke bear style" has no inherent meaning. Neither do the terms "beard" or "goatee", for that matter. That's why languages differ so much from each other, why they evolve over time, and why jargons - domain-specific language extensions - arise.
Meaning is determined by usage and usage is influenced by meaning.
Re:Maybe they've grown up a bit (Score:5, Insightful)
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 [thedailywtf.com].
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.
Re:Maybe they've grown up a bit (Score:1, Insightful)
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.
This myth has been repeated to death thousands of times over the years, and disproven on nearly every occasion. Every micro-optimization C++ newbie thinks they can prove that the C++ STL results in slow code. Ultimately, the cause for his results are of writing inoptimal code.
But it seems you didn't even get that far. From what I gather from your post, I'd guess the last time you used C++ to be sometime near the year 2000. Maybe you should check again; C++ compilers have advanced much since then in many respects.
As the STL is good enough for many game developers, I heavily doubt you have the experience to prove it is actually slower. You can read about EA's inconclusive experiments in their EASTL paper [open-std.org]. EA's replacement STL provides more efficient container allocators -- allocator replacement is a feature of the STL and something all C++ programmers do at one point -- and mainly optimizes the STL for console C++ compiler deficiences (usually poor templating support).
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.
No one cares about OOP in C++ anymore. C++ truly has no advantages for it. C++'s unmatched advantages (except for in D) are in compile-time metaprogramming, or generic programming. As you are citing the STL, you should understand this. If the STL were written in terms of runtime polymorphism, it would be much slower due to no longer generating C-optimal code.
Re:The devs don't know C++?? Its a C++ compiler! (Score:1, Insightful)
I think you're confused. Strictly speaking, GCC isn't even a C compiler.
Given the GNU Project's fetish for "cleverly" misleading names, I don't think it's fair to call the GP "confused" when he/she was referring to gcc and could have simply decided to capitalize the initialism like a sensible person would. gcc is indeed a compiler that does not compile C++; g++ is a compiler that does compile C++; both are part of the software suite that the GNU Project sadistically decided to name GCC.
Re:Maybe they've grown up a bit (Score:3, Insightful)
Why not test it yourself? I did, but I've come to realize that the only way for people to actually believe it is to get off their behinds and test it for themselves. Otherwise, it's too easy to dismiss.
It's the same as everyone who claims java is "almost as fast as c" when in a lot of cases it is piss-poor. Test it.