What's new in GCC 4.5? [LWN.net]

What's new in GCC 4.5?

Posted May 14, 2010 2:40 UTC (Fri) by pr1268 (subscriber, #24648)
Parent article: What's new in GCC 4.5?

GCC 4.5 is the first release of GCC that can be compiled with a C++ compiler.

I had to think about this for a moment. Why? Isn't GCC already working just fine (i.e. fast and [reasonably] efficient) as is in C? Then, visiting GNU's GCC page link in the article, I began to wonder if the developers want to use those features of C++ not present in C for the compiler? (Like classes, OO, and templates.)

Of course, any compiler can be written in any Turing-complete language. Even the 2nd edition of the Dragon Book has the source for a front-end written in Java.

My questions border on rhetorical, but perhaps I'm just trying to stimulate a discussion on this. Thanks!

(Log in to post comments)

What's new in GCC 4.5?

Posted May 14, 2010 9:35 UTC (Fri) by jwakely (subscriber, #60262) [Link]

Compiling gcc with a C++ compiler has already uncovered a number of latent bugs, such as comparing values of enum_type_1 to values of enum_type_2. That's not an error in C, because enums are just ints, but in C++ they're distinct types and the compiler catches the problem. I hope stronger typing would also mean less casting to/from void*.

As well as increased type-safety C++ gives you automatic memory management (via destructors) which could potentially replace the garbage collection used today.

Gcc uses lots of hash tables and vectors internally (the VEC type mentioned at the link you gave) which could be replaced by standard C++ containers - although that's a bit less certain, as it would require a working C++ standard library as well as C++ compiler to bootstrap.

There are of course downsides to C++, so let's not have a language war here :)

What's new in GCC 4.5?

Posted May 19, 2010 21:46 UTC (Wed) by roelofs (guest, #2599) [Link]

Those are excellent benefits, and I've come to like C++ for such reasons--as long as one doesn't go overboard, of course. C++ can lead to "write-only" code, i.e., easy to write, impossible to maintain. One needs a little discipline and design sense, which I'm sure the GCC folks have in abundance. (Doug Crockford has made similar comments about JavaScript, btw. Just because the language officially supports something doesn't mean you should actually use it. :-) )

One unforeseen drawback we encountered, however: generated code size (that is, binaries) exploded. A 15 MB C-only executable grew to ~600 MB as parts of it were rewritten in C++. I still think it was worthwhile overall, but holy cow...don't underestimate the pain of creating, deploying, loading into memory, and core-dumping huge binaries. (Some of it might have been due to symbol visibility; I never had time to investigate. I think quite a bit was due to template use. No doubt you guys will figure out ways to keep it under control in GCC...)

Greg

What's new in GCC 4.5?

Posted May 20, 2010 3:56 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

A 15 MB C-only executable grew to ~600 MB as parts of it were rewritten in C++

That's huge! There's no good reason to tolerate that level of bloat. Was that with or without debugging symbols?

Part of the cause is almost certainly forced inline function generaton. Using hidden symbols allows the compiler to skip the generaiton of certain functions --- if they're private symbols, the compiler can assume they're not overwritten at load-time.

Another thing to keep in mind is C++ template generation, as you mentioned. It's easy to achieve a combinatorial explosion of template instantiations when you have a template library used in many difficult circumstances. It's often worthwhile to have generic, templated code just be an inline-only, typesafe wrapper around concrete code; use function pointers to let that concrete code safely work with whatever the higher-level wrapper gives it.

Using that approach, you give up a tiny bit of runtime performance for a huge reduction in code size. Imagine the difference between qsort() and std::sort --- it's easy to write the latter such that the entire sorting agorithm implementation is emitted once per type sorted! (It's also possible for a C++ library implementor to write std::sort using the type erasure technique I mention.)

What's new in GCC 4.5?

Posted May 20, 2010 10:03 UTC (Thu) by jwakely (subscriber, #60262) [Link]

See http://www.cs.huji.ac.il/~dants/papers/MinimizeDependenci... for another technique for reducing template instantiations without having to resort to function pointers.

What's new in GCC 4.5?

Posted May 30, 2010 1:01 UTC (Sun) by roelofs (guest, #2599) [Link]

Was that with or without debugging symbols?

With. In this application, auto-gdb-backtrace was pretty much a necessity.

I'm no longer working on that particular project (or even in C++), but I'll keep jwakely's and your suggestions handy in case it crops up again.

Thanks,
Greg

What's new in GCC 4.5?

Posted May 15, 2010 10:28 UTC (Sat) by nix (subscriber, #2304) [Link]

Your implication here is that the GCC developers are trying to go to C++ because they haven't mastered C. Nothing could be further from the truth. GCC uses every C coding trick going and then some (with one single exception: no tricks relying on GCC extensions are used in the middle-end or C frontend because they must be compilable with non-GCC bootstrap compilers, and no tricks that bootstrap compilers choke on are allowed there either, which is why everyone hated trying to bootstrap with the horrible HP-UX 10 bundled C compiler). The language it's written in uses so many elaborate macros it's barely even C anymore (in this it is similar to many other large C projects). And that's the problem: many of these macros are intrinsically non-typesafe, and bugs *do* crop up as a consequence of this.

Regarding the 'free up a pointer' thing, well, this proved so intractable to get right for GCC (where many objects have extremely hard-to-describe and interacting lifetimes crossing many passes) that it ended up with a garbage collector simply to lift the burden of manual memory management from the developers; it is not known how many bugs this fixed, but it was surely a lot. (Some heavily-used objects have since been shifted back from GC for speed reasons, but it's a case-by-case judgement whether to *not* garbage-collect, rather than vice versa.)

What's new in GCC 4.5?

Posted May 15, 2010 14:57 UTC (Sat) by HelloWorld (guest, #56129) [Link]

<blockquote>C "bugs" of taking-everything-programmers-throws-at-it is actually a "features".</blockquote>
This is *exactly* the kind of *bullshit* that keeps the same bugs happening over and over again in C programs.

Good programmers think about their code anyway, but no matter how good they are, they *will* make silly mistakes, and if the compiler (or whatever else) catches those, then that is a Good Thing.

What's new in GCC 4.5?

Posted May 17, 2010 8:10 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

>A feature that force developers to think very carefully of what they are trying todo. Having to thought it for 5 times of whether it is possible to free up a pointer. Check a million times for dangling ones.
And get a Schrödinbug when you (almost inevitably) miss one.

I like C. I like C++. I am not so enamoured of either to call it a flawless or even merely universally superior choice in all problem spaces.