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.
C++ is the most horrible language I've ever had to write code in. I think they should have sticked to pure C.
Although I am not a contributor (for now at least, maybe), I want to follow how the developers will transition from C to C++. I mostly use C at work but I want to learn C++ as well. However, most of the time, I'd rather code in C than in C++ because I am that uncomfortable with it. Maybe the last time I used it is back in college, and that translates to not knowing much of it at all.
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... ^_^
How do you compile a compiler written in the language it compiles...
Admit nothing. Deny Everything. Make Counter-accusations.
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.
that they are in need of ObjC without garbage collection. Why use C++ and artificially constrain its capabilities? There is also GnuStep project and ObjC has a clearer and simpler syntax than C++ with single object inheritance, and C99 extension (easy migration path). I cannot understand their reasoning for C++ if they are targeting a single subset and not the full standard. The only plus for C++ is the extensive use of IDEs. Otherwise it makes no sense.
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.
Will this feed through to things like AVR-GCC for Atmel AVR 8-bit microcontrollers?
I wonder what changes in performance we would see.
http://winavr.sourceforge.net/
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?
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.
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.
Here's somme ammo from bash.org:
In Soviet Russia, our new overlords are belong to all your base.
They'll implement the new machine code generation routines in C++ just like now, and then cross compile gcc.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
$ 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-linux
Reading specs from
Target: i486-slackware-linux
Configured with:
Thread model: posix
gcc version 4.3.3 (GCC)
That looks like gcc to me
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
C++ is 80's technology, and as such filled ugliness that was considered sexy at the time. Just like 80s pubic hairdressing it's just too much to see the essence. Try to compare Haskell's polymorphism to C++ templates and you will get the picture. Anyway, to you really think 30 years of computer science since C++ could not come up with anything better? Why not take advantage of the fact that you are very late in taking up a new technology and skip a few decades?
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...
I have a Caldera OpenLinux T-shirt from back in the day. I still wear it around once a week (because it's the only linux tshirt I have)
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
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...
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?
Sure it can be abused, if you're overloading operator+ to insert records in a database you're doing it wrong.
OTOH operator[], operator*, operator-> and even operator are fundamental to data processing - you can't remove them from C++ without doing a lot of harm.
Anybody who advocates removal of operator overloading has completely missed the point - yes they can be evil but the good far outweighs the bad.
No sig today...
Subject line says it all. C is the best subset of C++ there is or ever will be.
(assuming you've got a decent C++ compiler...)
Seriously, how can you live without RAII, etc.?
No sig today...
Wait....C++....standards?
DOES NOT COMPUTE
*Head explodes
Monstar L
I don't see what the problem with virtual functions is. He goes on and on about 'added overhead' but the overhead isn't added unless a programmer types the word 'virtual' somewhere in the source code. Presumably the programmer expects to get something in return for typing it... therefore the overhead is acceptable. QED.
Templates - how will they do STL without templates??? Seems like a big fail to me.
Exception handling ... probably not needed in a compiler. A compiler isn't likely to want to recover from a fatal error.
RTTI ... probably not needed either and usually quite easy to work around for the few cases a compiler might want it.
No sig today...
And, of course, this will slow down the compiler at least twice, maybe even more.
C++ is good, but C is best. Ever wondered why the kernel is written in C (with lots of assembly spices), not C++?
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."
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.
There's a sig I see around here, about religions: (paraphrased) "If you need government to enforce your religious rules, what does that say about the strength of your message?"
If we* need to make it impossible for proprietary software to work with free software in order to sell** the free software, what does that say about the strength of our message and our ability to compete, feature/tech-wise? :(
I give all my moral support*** to the GNU project, which has the goal of enabling people to use only Free Software(tm) and Get Their Shit Done(tm). Making free software worse for the purpose of making proprietary software more worse (say, as in non-existent) runs counter to the purpose of the GNU project. Don't do that. Be pro-free, not anti-proprietary.
* The "freetards" :D
** lit. "make people use", fig. as in "selling [someone on] an idea".
*** including by wearing @gnu.org in my mail address---but I don't represent anyone but myself.
Obj-C is a pure superset of C, unlike C++. This means you can compile straight C programs with no changes. This means it is just as fast and typed as you want it to be up to the speed of C. Learn something about the language before commenting on it.
How could they have written a complier for a language they don't know? You do realize that GCC already does support C++? This means the GNU guys are admitting they don't know the language that they already wrote a complier for? How good a C++ complier could GCC be?
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.
when does the file handle get freed? Ass.
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.
Actually, not so much as you might think.
Over a lifetime of programming, I've spent far FAR too much time debugging problems in compilers (from UCSD, IBM, Sun and even GNU compilers) and "MyClassAddFloatAndInt()" is inevitably going to be mangled at the Assembly or machine code layer where you will work to identify and demonstrate most compiler bugs.
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.
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,
Nice to see they are not easily swayed by the "fashion victims" of more recent languages.
need a free COBOL editor for Windows?
I thought compilers would chop the incoming text up into lots of little strings and put them in an array of tokens, to me that says std::string and dynamically growing containers - much more robust than malloc and strcpy.
The expression evaluator will need a stack along with typed data items (int, float, double, etc). C++ can make that sort of thing much neater.
If you dig into it, I'm sure there's many places where C++ would remove a lot of lines of code from a compiler.
No sig today...
Someone's bound to be shot in the foot for this.
"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." - by mog007 (677810) on Tuesday June 01, @07:51AM (#32416784)
See subject-line above, & this URL:
http://www.jamesshuggins.com/h/tek1/grace_hopper.htm
(IIRC, also/additionally? The lady's also an admiral too!)
APK
P.S.=> It's often said there aren't many women in computing, & compared to the male population involved in it? Typically, it's true! HOWEVER - When there is a woman involved in computing? They surely make a HUGE showing for females' sake (imo also, another one is my fellow polish-person, in Joanna Rutkowska also, & more currently (albeit moreso in the realm of computer security, but, she's far from a slouch in coding also))... apk
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.
C++ can be very lean and mean indeed.
Can be != is. A statically linked C++ hello world program using <iostream> is still on the order of a quarter megabyte even on recent versions of g++ and libstdc++. This hurts when you want to use C++ features on a memory-constrained embedded system. Consider a handheld computer with 288 KiB of RAM that sold tens of millions of units between 2001 and 2006. If the libraries needed to run hello world eat up all the RAM, how are you going to fit the application?
"Hello World" pulling in glibc non-necessarily...
http://developers.slashdot.org/article.pl?sid=10/03/16/2216258 if bloat & bug-interaction is what they require, they're gonna be clobbered by it, and so are we who depend on the toolset.
Fashion isn't intrinsically intelligent: many a species has gained a Darwin-award for socially-pushed change...
( if I'm wrong, then good: state how, so we all can see truth. I'm just going on what understanding I got )
There's no equivalent to RIAA in C
That's only because the standard C library has no audio output facility. Did you mean RAII?
there's also no equivalent to stack unwinding or many of the other C++ constructs which are central to good C++ programming.
But how big is the library support for those C++ constructs? Once you #include <iostream> and reference cout, your statically linked hello world already almost fills RAM of your elevator controller. Do you want to see byte counts for a static hello-iostream.cpp on two different platforms?
ability to declare variables in the middle of code blocks
That's been in C for the past decade.
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.
In C++, you pay for what you use. If you don't throw, and you don't link to a library that throws, then you won't have exceptions. I guess their problem is that the standard library uses the version of operator new that throws std::bad_alloc on failure rather than the version that returns a null pointer.
Maybe they don't want function overloading
You can disable overloading for a function by putting extern "C" before the name of the function's return type.
Extended initializers
Something like that is already in C99.
Can the C based versions be labeled clearly for those who prefer a gcc written in C only? If this is not possible, it may be a good idea to create a fork for gcc in C for those who may need it. Ideally, a compiler flag that can switch to C only version if requested would be good.
Seeing as how GCC now supports them both, why not use one of them instead?
Having done a little work with this, I think kernels are written in C because of issues with the runtime library. The C++ runtime is more complex to get up and working, and a kernel needs a different runtime library than the rest of the system because it has a different memory map and it doesn't make syscalls to the kernel to make things happen at the back.
Also, in the kernel there are plenty of places where you don't want anything happening between point A and point B that allocate memory or touch user space or manipulate semaphores or whatever, because you're in a critical section. Well, part of the whole design of C++ is a single statement can turn into dozens or hundreds, and often these statements will auto-allocate (and de-allocate) memory for you or use other resources. So you'd have to be real careful if you used C++, so careful that I'm not sure you get much from C++ except namespaces.
So in short, I think the reasons kernels don't use C++ cannot be directly applied to a compiler. It has its own reasons (primarily bootstrapping) though.
Also, kernels don't use much assembly, I'd say "lots of assembly spices" is an exaggeration. You can never get the amount of assembly down to 0, but neither do you use it that much.
http://lkml.org/lkml/2005/8/20/95
There is a myth out there that object oriented code produces better quality code then procedural programming.
I say myth because scientifically it has never been proven that code quality improves with compiler discipline.
All claims about less bugs per lines of code, easier to maintain, etc are purely anecdotal and speculative. When I studied this back in the early 1990s the primary impedance to any objective analysis comparing like for like were cost prohibitive. Any effort that involved a change in language also incorporated a change in design. People who wrote the original implementation were replaced, etc. etc.
One could look at this as a teaching moment.
Someone needs to step up and prove that compiler or language discipline increases code quality holding the developer constant.
The claim is that a programmer using a different compiler or language produces better quality code. It has been shown scientifically that a C compiler will mostly produce better performing code than code written in assembly. It has never been proven that compiler discipline can make a better programmer. If it has been proven than someone should be easily able to point that proof the to GCC crowd for them to use as an arbitrator for where to draw the C++ line.
The only argument that makes sense with respect to object oriented languages is that they afford a toolkit for upfront design. The large project architect has tools to layout the design for the implementers to essentially fill in the blank. Stroustrup predicates his entire C++ book on this point.
However, it doesn't appear the design features of C++ are the objective here. The objective here is code quality via better syntax, and is this is a claim that has never proven. Its a modern myth.
This is really not a discussion about C++ vs. C, but rather the modern myth that any given developer produces better quality code by compiler discipline.
Yeah, but have they tried JavaScript?
[Linus] sustained that C++ is utter crap
I thought he said C++ is an overloaded piece of shit?
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
It's sad. C++ has major problems, which are well known. The fundamental problem is that C++ has hiding without memory safety. C++ is unique among major languages in that respect. There are languages with no hiding, (C, assembler) and languages with both hiding and memory safety (Java, Delphi, Go, D, Ada, Modula, Erlang, Eiffel, and all the "scripting" languages).
The C++ committee, and Strostrup, are in denial about this. They're off in template la-la land, trying to abuse the template system into a compile-time interpreter.
C has its own problems. The basic one is that you lie to the language about how big things are. A string parameter is declared as "char *", not "char[n]". So the language has no idea how big objects are. It doesn't require garbage collection or array descriptors to fix this. It just requires a declaration syntax where you can talk about the size of the arrays you're passing around. This fundamental defect in C is the cause of most buffer overflows. (Technical discussion: C should have had array parameter declarations like int read(int fd, char[n]& buf, size_t n); rather than int read(int fd, char* buf, size_t n); Then the language knows how big the array is. This could be extended to structs, etc. so that whenever you have an array, there's an expression known to the compiler that defines its size. This allows subscript checking.)
C++ tries to paper this over with collection classes, but the mold always seeps through the wallpaper. Too often, you need a raw pointer, which breaks what little protection the collection classes provide.
I've been there and seen how it works. We had C++ project which used to have strict rules what kind of stuff you're allowed to insert. It starts by people following the rules, but they silently think the rules not worth the effort; but immediately when you give green light to make the rules less restrictive -- like gcc going to c++ is going to make all the wannabe c++ programmers want _all_ their restrictions gone.
Here's why:
1) First they will have lots of rules what kind of code they allow
2) But people will ignore those rules, because why can't we use _all_ of C++, if they allow _any_ of C++ code in.
3) Next their code will be full of STL and all kinds of stuff that interacts very badly with existing C code
4) then their compile times will be very slow. It will take lots of time to compile it. Developers gets bored because they're not developing but only waiting for computer to compile the code.
5) then the project dies.
I've seen it happen before, and the this news about gcc going to c++ sounds exactly the same pattern. The reason they need to go to c++ is because they get complaints about the restrictions that they're enforcing. But it's big mistake to remove the restrictions or part of it. It'll not stop there -- people will want all their "unnecessary" restrictions away. And that has a chance of killing the project.
There are also plenty of lean and efficient vector/list/hashtable libraries in C. I hardly see the point of promoting the STL. Moreover, GCC probably already feature lists and stuffs, and has been for years. Therefore, I don't see exactly what is the point at saying that STL is more this and that, compared to what already works in GCC ?
I had a Caldera OpenLinux CD. I gave it to the Jehova's Witnesses one Sunday morning when they called round in exchange for a leaflet about Armageddon.
Stick Men
OhyouwinagainInternet.jpg
I thought compilers would chop the incoming text up into lots of little strings
Thats the abstraction. You know that this can be done in many ways, right?
...or it could use a hash table to associate the token with a number assigned to it, and pair that with an auxiliary array (indexed by that number) that stores information about the token.
It *could* use your sloppy and memory-hungry std:string crap...
In short, you are basically educated in step one of abstraction, but not the implementation.
The expression evaluator will need a stack along with typed data items (int, float, double, etc). C++ can make that sort of thing much neater.
First, regular old C was designed to make implementing stacks simple. Pre-and-Post increment-and-decrement is absolutely all you need .. in short, the damn thing has operators specifically for stacks and queues. I will repeat the assertion that the only thing STL brings to the table is generic containers. The key word is generic and you havent justified a need for them.
Your datatype argument is not well educated, I am afraid, since STL containers are only generic prior to compile-time. In short, they are not run time generics so STL doesn't add anything for a compiler in that regard. The compile needs to treat things as arbitrary datatypes at runtime, and in that vein OO in general is no better than flag/feature bits and function pointers. Either way it needs to perform tests, branch to specific processing or output routines, etc..
If you dig into it, I'm sure there's many places where C++ would remove a lot of lines of code from a compiler.
Why don't you think that its just as likely that it will require more lines of code? You need to think this through, because OO is most certainly not heralded for enabling shorter program sources.
"His name was James Damore."
Good luck implementing exception handling.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
If you test it, you'll also see that you're wrong, unless you're running debug builds (in which case you're not comparing apples to apples, as the STL versions will have massively better debugging capabilities).
Badly written code is slower than well-written code for sure, but there's nothing about STL that makes you write bad code. (Nor does it stop you writing bad code.)
The ANSI C committee adopted const from C++ in time for the first ANSI C standard, 21 years ago (sadly not calling it "readonly").
(You make a valid point about not having to use every C++ feature to get benefits from using some, and I believe that the plan is to be conservative in introducing features that are helpful while avoiding more controversial or complex features.)
You use a cross compiler. But it is painful - GNU Ada is self hosted and moving Ada to a new platform is quite painful. But once done it's a lot more fun. Why should Ada, Fortran or C++ advocates be forced to use C to improver their favourite compiler.
And maybe the move to C++ also means better cross compiler support.
Anyway: self hosted Fortran next!
Actually not all gcc is written in C. The Ada front-end is written in Ada. I think it is the way to go, all language front-ends should be self hosted.
rockets and reactor software should neither be written in C nor in C++. For those you should use SPARK Ada:
http://en.wikipedia.org/wiki/SPARK_(programming_language)
And funnily enough: GCC Ada is written in Ada. Because the real (not pseudo) high integrity developers won't trust a language which (easily) allows to cast a pointer to an integer.
Different name mangling between different compilers is deliberate, and a good thing: it stops you linking together code that uses incompatible ABIs, and then getting strange crashes.
Now, if you want to complain that it took too long to standardize ABIs for C++, and that it's too hard, and that they're not stable enough, then you might well be able to make a pretty strong case, but that's a different thing. If your ABIs don't match, you shouldn't make your name mangling match.
(Incidentally, if you code in a sane way then the implicit copy operations _almost_ always do the right thing. It would still be better if we had to explicitly enable them, but that would have broken C compatibility, or made struct vs class into two different worlds.)
C makes bitwise copies. C++ makes memberwise copies (and in simple cases, can optimize that to a bit copy). In C++ you'd hold a smart pointer, and copying that would do the right thing (whatever the smart pointer defines it to do: ref counting, causing a compilation error, making a copy of the target).
Copy operations in C++ would probably not be implicit, if it weren't for the fact that they're implicit in C.
It is a library for generic algorithms, decoupled from data structures via STL's notion of iterators (which is rather different from GoF iterators). As a proof of concept it happens to provide some containers that work pretty well.
There are many problems with your example.
Don't you see what is going on here? Even the most trivial feature of C++, constructors, are horribly ridden with complications. C++ is a language of never-ending surprises, gotchas, land mines. It's a trap.
Let's knock those down one at a time.
I will repeat the assertion that the only thing STL brings to the table is generic containers.
Wrong. It brings generic containers and algorithms. But saying it like that somehow diminishes what it brings to the party. Its a lot like saying, "Pah - using doctors can ONLY save your life. Its no big deal."
As for reduced line count, the GP post is absolutely correct - assuming you're not counting the generated code associated with STL's template instantiation. Which frankly, is generally not considered for line counts. So if you have many different data types which must otherwise be tracked, in C, you have many different implementations of hand crafted code to handle all these different types - generally all doing the same thing. Or, you've generalized it (void * plus a magic/type in a structure) and thrown away the limited type safety provided by C. Or, you can replace all that, while adding additional type safety with fewer lines of code. Additionally, the STL implementation is far more likely to be much, much faster, not to mention bug free; especially for more complex containers and algorithms.
"Still undecided is what subset of C++ to use".., they need to identify their core needs to answer this question. I would really like to see what they actually come up with. This might be good news..., i hope.
So, now it's GC++C++?
Currently, to understand all of gcc you need to understand C. If parts of it start to be written in C++, then the developers who only know C will be unable to understand all of gcc. So you'll be limiting the pool of developers, not increasing it.
Imagine a C developer debugging or developing and tracing through a call sequence only to discover that suddenly the code in question is C++. Suddenly their skills aren't enough.
If C++ is used only for the code that's used to implement C++ itself, the above issue is not so bad. But I wonder how the purity of the non-C++ parts of the collective will be assured. It sounds like a tricky code management problem.
I'd also be interested to see a study comparing the bug rate and bug fix rate for C++ vs C. My personal observations are that both are better with a simple language rather than a very complex one.
Frankly, this decision seems like a very bad one, and one where the impact will be felt very gradually, with increasing weight over time.