GCC Switches From C to C++ 406
According to a post on the GNU Compiler Collection list, GCC is now built as a C++ program by default. This is the fruition of much effort, and the goal now is to clean up the GCC internals that are reportedly pretty type-unsafe by rewriting them using C++ classes and templates.
Re:too bad GCC is not relevant anymore thanks to L (Score:4, Insightful)
Don't be so bold in claiming most embedded platforms are something.
Most embedded platforms use Keil, Assembler and all kinds of various odd proprietary compiler suites that suit their 8-bit and 16-bit nature better. The elitist, narrow though visible of 32-bit ARM is using GCC.
I assure you your refrigerator temperature thermostat was not programmed in GCC.
Re:Classes/Templates are not a magic bullet ... (Score:5, Insightful)
Bad code is bad code, and you can write it in any language, yes, even visual basic.net.
So the point is not so much "how useless are those lousy GCC devs who will write crappy code", but "how good are those GCC devs now they have a more powerful tool in their hands".
I'd hope they start to discover the STL too, and use the standard containers at the very least - no need to use custom ones unless you either continue to use the existing C-based ones, or you have some very specific performance issues that you absolutely cannot fix any other way (and generally, you don't have this problem with the STL)
Now, sure, I hope they don't discover cool new features like STL algorithms and start to litter the code with lamba-d functors.
Awesome (Score:5, Insightful)
GCC as a compiler and a community seems to really be moving, it is probably due to the competition from LLVM, but atleast for now, GCC is still the better compiler, and I wish them the best of luck.
Good compilers benefits everybody!
Re:GCC should remain small and fast (Score:5, Insightful)
I used to be more polite to ignorant C++ haters. But I've lost patience.
A program written in C++ is going to be slower than an equivalent program written in C, no way around it.
There is a way around it: by not being an astonishingly incompetent developer.
And that's without even getting into features like templates, which only five people in the world understand.
Don't assume everyone is as dim as you.
Re:Compiler bootstrapping? (Score:2, Insightful)
Not much.
You can cross-compile all you like.
If that fails, and you find yourself on a system with only a K&R C compiler, you bootstrap to
an ANSI C compiler by going to gcc 2.95.n or something like that. Then you use that to get
to a fairly recent C-based gcc and finally use the resulting C++ compiler to compile the
final version of gcc.
Re:More like "C with Classes" (Score:3, Insightful)
I've gone the opposite direction. Moving more of my C++ code into C by using my own OOP system. Before you say "That's crazy talk", consider that it makes inter-operating with my game's scripting language so much more buttery smooth than in C++ -- It's so nice to just create a new object in either script or C and have them talk to each other without going through a few layers of APIs, passing off dynamically allocated instances and having C free it, or the script GC it automatically.
Don't get me wrong, I love C++, but they have rules that are conflicting when you get "deep" into the language. Try using multiple inheritance and polymorphism... It almost works, but not if you have two base classes with the same virtual function names -- That's just one of many edge cases I ran into... Theres several corners we're forbidden to go where templates, type safety, and inheritance don't play well with each other...
After a while I just scratched my head, "Really C++? Really?!" Why would you have features that are incompatible? So long as I only use some of C++'s features some of the time, then everything is fine, but when I needed to use MOST of the language in the implementation of my scripting language, then shit hit the fan. Many experience people I look up to have told me if I need to use the WHOLE C++ language then I'm doing it wrong. To them I say: If you can't use the entire language at once then the Language is "doing it wrong".
C++ is great if you're only using C++, and C++ constructs. That you have to use extern "C" { ... } to make shared libs that will actually work with other compilers or languages is a serious show-stopper for me. Protip: method names are munged into unique C function names so you can actually compile "C++", ergo they need to standardize name munging rules but to do that would be to admit that C++ is mostly implemented as a fancy pre-processor for C...
Most of my C++ code was contained in extern "C" blocks, and I had abandoned most of the C++ features for my own language's simpler implementations, so one day I woke up and realized I should stop fighting C++ and just use C.
My problem was that I needed a language that let me closely express the construct of another language within it -- embedability was a prime factor. Sure I could write the VM in C++, and have a ton of interfaces and abstraction and overloaded operators, etc, but with C I didn't need to do that.
Some of the reasons I left C++ for are being fixed / added in C++2012, but it's too late for me. I'm not going back. I'll use C++ for my C++ only projects, but for anything that needs to work with other languages (most of my code), then I'll use C. Bonus: Instead of 15 minutes to compile the C++ implementation, it takes just seconds as C.
C has many pitfalls, but at least they're out in plain sight; Unlike the C++ pitfalls, which are hidden in corners, shrouded in "advanced feature" mystery, and blanketed by the fog of denialism -- When things that should work according to spec don't (because of the implementation details), then you do you really have a language, or is it just part of a language?
C++ has the same problem with C that I experienced with C++ -- When you try to implement a language in a way that's really close to another language, so you can use its underlying tool-chain, you run into a point where you must be shackled by the base language's implementation details... You can either build around the limitations (what C++ does), or you can embrace them (what I've done). Unfortunately I couldn't embrace the C++ implementation -- a complete one doesn't exist.
Re:Classes/Templates are not a magic bullet ... (Score:5, Insightful)
You can do all kinds of nifty stuff with macros and gcc/clang extensions to provide type safety to C
Yes, I know.
You can write a GENERATE_SORT(Type, Comparator) macro which generates a sort function to work on an array of Type, using the specified comparator, and has no name collisions and is type safe using liberal amounts of ## and so on.
The point is not that you can't do them in C (you can), but the methods for doing it are ad-hoc. By moving the functionality into the compiler, C++ provides a regularity of syntax for such things that C lacks.
Re: progress (Score:5, Insightful)
No. 22 more years has seen Challenger and Columbia blow up, and we've learnt some lessons about things we should do and things we shouldn't do. Just as the Challenger investigation didn't conclude, "Ban O-rings," nobody has decided to ban parts of C++, either.
C++ is in some ways like a human language: It has an enormous range of things you can say in it. Some of them are only appropriate in certain situations. Some of them are never appropriate if you want people to take you seriously. Some of them just plain don't make sense.
So quite a lot of the development over those 22 years has been in the community learning idioms that let you use the power of C++ without hurting yourself.
Re:Classes/Templates are not a magic bullet ... (Score:5, Insightful)
I don't write 'university code' though; and I'm not out to impress a professor or win 'elegance awards'.
I think the enormous chip on your shoulder might be obscuring your view of C++.
Re:More like "C with Classes" (Score:4, Insightful)
When I realized that my array of Boolean objects in C++ was an order of magnitude more memory intensive than the bit-arrays I could create in C
Dude, std::vector<bool>. All of the iterable, dynamically-resizable, type-safe goodness of a real array type with very nearly all the efficiency (time and space) of hand management of packed bit arrays. The only downside is that you do have a little extra bookkeeping info (an int) to support the dynamic resizing. If you need to avoid even that, there's also std::bitset, which has a length fixed at compile time. Odds are that code using std::bitset will be more efficient than what you'd write, and you don't have to waste brain cycles on "keeping track of the fact that it's a pointer to a bunch of bits".
There are some reasons to prefer C over C++, but your example is decidedly not one of them. In fact, it strongly favors C++.
Re:OOM inside STL (Score:4, Insightful)
Actually the correct comparison is to not only disable exceptions in the compiler, but in addition adding hand-crafted error handling to the code. Because manual error handling also costs performance. And without error handling, your application is broken, period (and yes, I have been bitten by applications doing improper error handling. And yes, that included data loss. Loss of data stored on the hard disk, because the application didn't do any error checking when replacing the file with a new version. Fortunately I could get back most of it from the nightly backup).
Re:too bad GCC is not relevant anymore thanks to L (Score:0, Insightful)
That may be true but it was because GPL forced them to give back when Apple was still using gcc. Apple doesn't like giving back. They stated as much as their motivation for using llvm. They said that they did not want to have to share their code generation optimizations as their motivation for abandoning gcc.
If you like parasitic companies (in this case Apple, but there are many) leaching off your work, release with another license, but if you like a healthy community, GPL seems to be the best choice.
Although this whole thread seems to have veered way OT!
Re:too bad GCC is not relevant anymore thanks to L (Score:1, Insightful)
Stallman is a gentleman with a name.
You on the other hand are a confused big mouth coward.
Re: progress (Score:3, Insightful)
Re:Type unsafe... (Score:3, Insightful)
> language, it just happens to be unparsable by humans.
What on earth are you talking about? Lisp is extremely trivial to parse. Lisp barely even has syntax.
Now, keeping track of Lisp program flow in your head, that can be a bit tricky and can lead to some substantial maintainability issues, especially when some hotshot programmer starts throwing lambda functions around like there's no tomorrow (or, worse, continuations).
But parsing? Parsing Lisp is dead simple. You could train an elementary education major to do it.
Re:Classes/Templates are not a magic bullet ... (Score:4, Insightful)
For you, I suggest two-pronged approach to C++. First of all you have libraries and frameworks. They take full advantage of C++ features, but hide them. Then you have the actual application code that uses these libraries, and is much simpler, ideally readable by somebody who only knows Java or C#.
The difference to doing the same in C is, in C you'll use macros and have poor type safety, ugly-looking code and get obscure macro related errors when when you put bad stuff as macro arguments.
In short, the trick with C++ is, you don't use most of the features, unless you really have to. Note that you can write your current C code as C++ code, except use whatever subset of C++ features you think will make your C-like code better, and only when it actually makes it better. Limiting yourself to pure C is, IMNSHO, just stupid, unless you're coding for a small embedded system and don't want to include C++ runtime in it.