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."
Either that, or could we be about to see the beginning of a gcc/llvm compiler arms race?
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?
If you need web hosting, you could do worse than here
We have to pick through the preprocessor output to find the broken bits.
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.
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.
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. :)
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?
No, they don't. That's how they did it back when the first compilers were made. Now everybody just uses an existing compiler, or in case there isn't one, cross-compiles on another system. And if you aren't a compiler developer, you simply download a precompiled binary of the compiler you want, or purchase an installation disc with the binary.
Looking at the GNU Coding Standard which is used for gcc, whatever 'best practices' and style guideline they come with will make a good fireplace material ...
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.
SJW n. One who posts facts.
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.
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 for some examples. It's shocking how user-hostile GCC is in comparison.
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
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).
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.
No sig today...
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?
Subject line says it all. C is the best subset of C++ there is or ever will be.
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.
"His name was James Damore."
Awesome! Now the compilation process can spend 80% of its time repeatedly linking virtual tables and getting confused over pure virtuals, instead of spending 5% of its time running through the symbol table and 95% compiling. Remember, building i.e. X11 invokes gcc hundreds or thousands of times, once for each C file (and it invokes the C preprocessor too, and all kinds of other shit from the toolchain, once for each included file each time it's included).
Support my political activism on Patreon.
is this on topic because it's also in a dead language?
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 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.)
Microsoft is to software what Budweiser is to beer.
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.
I have a Caldera OpenLinux T-shirt from back in the day. I still wear it around once a week
You wear it on those days you want to get laid, eh?
Trolling is a art,
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++.
No sig today...
When I started programming for a paycheck in 1991, there were no viable C++ compilers for the obscure underpowered platform known as the IBM PC.
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.
There is no such thing as actual pass-by-reference. Sure, a language might have fancy syntax for it, but it gets boiled down to pointer-to-a-value-which-is-itself-a-value. C just skips the sugar.
Or even from the GCC build instructions:
- Michael T. Babcock (Yes, I blog)
Well, it depends on your compiler options and what subset of C++ you're talking about. Enable exceptions and you automatically get a slowdown in any function that declares a class with non-trivial destructor on the stack and does anything that can't absolutely be proven to never throw (such as an indirect function call, virtual call, or even [on certain platforms where hardware exceptions are magically turned into C++ exceptions] execute a single instruction). Yes, I know there are platforms with "zero-cost" exception handling, the problem is there are many many others without it.
Then there's the debate about how best to expose (better yet: prevent) sloppy coding. Yes, in the hands of an expert, C++ offers no disadvantage, but it's often very difficult to find fifty experts (all without excessive egos) to work together on a project. And when you're on a platform where cache misses are *horribly expensive*, making a loop slow is as simple as typing "virtual" somewhere in a base class of some type who's methods you're calling (this besides bugging out the method that was meant to hide the inherited definition). That sort of shit can take *ages* to track down because it's utterly nonobvious when you open up the loop that's being slow. Overloaded operators and, to an extent, function overloading are also commonly culprits in this sort of situation - though I'd say the benefits pay for the cost in these cases.
"Correct" C++, especially template code, besides taking ages to compile, also tends to run like shit in debug mode. Have you taken a look at the implementations of various std::algorithm methods? Layer after layer of overload selecting based on type traits. Do that in a loop and your debug build ends up orders of magnitude slower than a release because inlining is disabled. If your program's definition of correctness includes run time and you heavily use Boost or the STL, you can kiss your debug build goodbye and jump straight to printf debugging, because whereas you might have a 10% faster machine to counter the 10% cost of a debug build, chances are you're not going to have one 1000% faster just lying around somewhere.
And then you have scenarios where OO in general can encourage bad habits, so a language like C where it's possible but ugly helps keep people on the straight-and-narrow. In my experience, there's a lot of merit to that way of thinking, but a lot of the specific cases where it comes up are subtle I really don't have the time to convincingly back up the general rule with a thousand little seemingly unconnected examples.
Of course, I do use C++ a fair amount, limiting myself to whatever subset seems right for the job. It's entirely possible to do anything at all in C++, but that knowhow is resource that's rarer than you might expect and almost impossible to detect in an interview. If I had a project where I needed to hire a dozen other coders I would very strongly consider avoiding C (or, if I expect to have the time, be an utter Nazi about which subset of C++ I'm going to permit into the codebase).