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: (Score:2)
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: (Score:2)
After a few moments of thought, the answer seems obvious, so i'm ansing my own question. They will likely have a bootstrap C++ compiler written in C that is capable of compiling the full C++ compiler.
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:Seems odd... (Score:5, Funny)
Re:Seems odd... (Score:5, Funny)
With the nodes that insert a backdoor into the unix login program colored red.
Re:Seems odd... (Score:5, Informative)
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.
Re:Seems odd... (Score:5, Informative)
Re: (Score:3, Funny)
So you're saying that this "Grace Hopper" character, far from being the role model for (female) programmers that the official history posits, was actually a spawn of the devil, the mother of the business programming scourge?
And by the way, what kind of name is "Grace Hopper"? A thinly veiled reference to the Plague of Locusts, I tell you! Isn't that definitive proof? Brace yourself, Jiminy!
Re: (Score:2)
ie. They could use any of the current compilers for the 'bootstrap'...
Re: (Score:2)
That would be wasteful, they could however strip down one of the current compilers and make it a "bare minimum" of features necessary to support the compiler.
Re: (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.
Nope (Score:2)
They'll implement the new machine code generation routines in C++ just like now, and then cross compile gcc.
Re: (Score:3, Informative)
Re:Seems odd... (Score:5, Funny)
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.
Re: (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 ex
Re: (Score:2)
Since there are platforms for which C++ compilers exist you can compile the compiler on one of these and then cross-compile for the target platform.
This is also how you boot-strap a C-compiler on a platform it is not implemented for initially.
Re: (Score:2)
Yes, that is one way to do it, but my point was that gcc has always prided itself on being able to bootstrap itself with minimal work, and without cross compilation. Cross compilation was sort of considered to be "cheating"
Re: (Score:2)
I get your point.
It might be possible to maintain a "gcc-light" compiler written fully in C and then have the gcc build scripts completing this boot-strap compiler first. The gcc-light do not need to be fast or effective since it will only be used for boot-strapping. It might even be possible to make it as a pre-processor converting c++ into C.
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.
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: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:Maybe they've grown up a bit (Score:5, Informative)
Re: (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:Maybe they've grown up a bit (Score:4, Insightful)
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: (Score:3, Interesting)
Since this is Troll Tuesday I'll be blunt - that's absolute horsheshit!
In testing, performance can
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: (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: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: (Score:3)
The STL definitely can make your code run faster. For instance, the standard way to sort an array in C is with quicksort(), which requires a function pointer argument. This function is called for each comparison.
In C++, with the STL, you would use the sort() algorithm, which is inlined by the compiler. No function call. The resulting code can be an order of magnitude faster !
Read this report [stanford.edu] for some code and illustrations. The C++ code is easy to write and in their example still faster than a hand-designed
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: (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.
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.
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: (Score:3, Informative)
Here, let me fix that for you:
Using c++ might free you from having to do manual memory management - just make sure you type a free for every malloc, and that your free gets called when the object goes out of scope (usually in the destructor). Then as the stack pointer gets unwound, the destructor calls your free.
Have an explicit contract with any other objects or code that uses data this object has allocated - which you should be doing anyw
Re: (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: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.
Great (Score:3, Funny)
Out of the ashes and into C++ (Score:4, Funny)
Re: (Score:2)
Great idea!
Indeed.
This will surely help steal back users from LLVM/clang.
I hope so.
So, you don't think that writing in a higher level language will lead to better performance and features? Perhaps you should start campaining to have LLVM rewritten in assembly language (or the LLVM intermediate language).
As for licenses, time will tell. Back in the Bad Old Days, every vendor and his dog had their own compiler. Because most vendors were not terribly good at writing compilers, writing portable code was really
Re: (Score:3, Informative)
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: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.
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.
Re: (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: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.
Re: (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 in
Re: (Score:3, Informative)
Actually you have it almost completely backwards.
A program like "Hello World" with be much, much faster in C than any of the Java derivatives like C#. A language that has a runtime requiring an expensive initial malloc for it's generational GC and a lot of fancy class/assembly loading will be an order of magnitude slower.
However a long running application is where the language's JIT features really shine, as they're able to optimize and reoptimize whereas a statically compiled language cannot. This is wher
Re: (Score:3, Informative)
Actually there is, it's called array bounds checks removal and escape analysis. ;)
Incorrect headline (Score:5, Informative)
Re: (Score:2)
The devs don't know C++?? Its a C++ compiler! (Score:5, Funny)
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?
Re:The devs don't know C++?? Its a C++ compiler! (Score:5, Funny)
Car analogy time! You can be an expert car mechanic without knowing how to drive.
I'll get me coat...
Re:The devs don't know C++?? Its a C++ compiler! (Score:5, Informative)
I think you're confused. Strictly speaking, GCC isn't even a C compiler.
GCC stands for "GNU Compiler Collection". In that collection, there's a C compiler as well as a C++ compiler, a Java compiler, and many more (they are not completely separate, they actually share a lot of code between them). All of them are written in C, and the news here is they're going to be written in C++ in the near future.
Re: (Score:2)
GCC is both. The GNU C Compiler is a C compiler; the GNU Compiler Collection includes the GNU C Compiler, G++ (a C++ compiler), and maybe various other compilers (I can't remember whether GJC for Java, GNAT for ADA, or anything else, are part of GCC); these compilers share a lot of their functionality (abstract syntax trees, code generation), with the separate languages being multiple front-ends for a language-agnostic back-end. So it wouldn't be surprising if a number of the developers of this back-end did
Rubbish (Score:2)
$ g++ -v /usr/lib/gcc/i486-slackware-linux/4.3.3/specs ../gcc-4.3.3/configure --prefix=/usr --libdir=/usr/lib --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware
Reading specs from
Target: i486-slackware-linux
Configured with:
Re: (Score:2)
Parent is obviously one of the GCC developers.
Great ! Another printout to burn (Score:2, Funny)
Looking at the GNU Coding Standard [gnu.org] which is used for gcc, whatever 'best practices' and style guideline they come with will make a good fireplace material [kernel.org] ...
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 oth
Re: (Score:2)
Conversely, I'll keep rooting for LLVM because it's not GPL licensed.
Re: (Score:2)
Bad old days: did you ever try to write portable C or C++ code in the (say) mid 90's on UNIX? Or more recently on embedded platforms.
They all sucked. Now most of them use GCC, life has got a whole lot better.
That is what I mean by the bad old days.
And I'll keep rooting for GCC because it is under the GPL. It acieved what Stallman set out to do, make life one whole heckuva lot better for end users (i.e. me, the schmuck writing code) of the compiler in this case through the use of Free software. So yeah. I li
Re: (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 contribu
Re: (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 synta
C++ flame wars (Score:5, Funny)
Here's somme ammo from bash.org [69.61.106.93]:
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: (Score:2)
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.
There is nothing special about operator overloading. In any good language, you get used to thinking about operators as functions with a funny syntax. That removes all the myste
Re: (Score:2)
Any language can be abused. GCC does that a lot with C already and it is widely known (GLIBC is worse, BTW). The issue might well just be that with this fact known, they want to avoid having that problem just get worse with C++.
Re: (Score:2)
Yes...one of the BIG wins in OO programming is that each class works like a mini namespace. It seems like a minor detail to the C++ bashers but in practice it removes a huge burden from the programmer - all function names can be short and logical.
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?
Re:so now I can't grep for functions (Score:5, Funny)
Ummm... just right click the function name and select "Find all references" from the popup menu.
Re: (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: (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 sho
Hooray for a slower compiler! (Score:3, Interesting)
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: (Score:2)
C++ is also required to be more-or-less compatible with C, and with various different pre-standard dialects of C++, which both prevents removing some of unpleasant parts, and means that new features have often had to be added in fairly baroque forms.
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.
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...
Re:thus a disaster (Score:5, Informative)
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...
If the first thing you get from C++, coming from C, is exceptions, then you're going to be in a world of pain. Most people who started with C++ have trouble with it. For a quick indication why, see Code Complexity @ GOTW.ca [www.gotw.ca].
As a 10-year veteran of C++, I say to start with RAII [wikipedia.org], and since you're going OO, require everyone involved to learn the SOLID principles [lostechies.com].
Re: (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. :)
Re: (Score:3, Informative)
Re:What... (Score:4, Informative)
Enjoy [google.co.uk]
Re: (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: (Score:2, Informative)
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.
Re:What... (Score:5, Informative)
Or even from the GCC build instructions [gnu.org]:
Re: (Score:2)
Re: (Score:2)
The other compiler can be a previous version of the same compiler.
Re: (Score:2)
Re:What... (Score:5, Funny)
Quis compilabit ipsos compilatores?
ecco, tibi fixi .
Re: (Score:2, Interesting)
Re: (Score:2, Troll)
Re:From the article it is obvious (Score:5, Informative)
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).
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-determinist
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:80's technology (Score:5, Funny)
Yeah, exactly. I don't understand why they didn't chose something modern like Ajax.
Re: (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: (Score:3)
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
Re: (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 perfo