GCC starts move towards implementation in C++ | Hacker News Reader

GCC starts move towards implementation in C++

article.gmane.org

42 pointsAnon8435 comments

I find this statement particularly interesting:

For example, I think constructors and destructors are pretty easy and hard to misuse.

Now, I am aware that the competence of the average GCC committer probably exceeds that of the average programmer, but still, constructors and destructors are easy to misuse: throwing an exception in the constructor comes to mind, in which case the destructor isn't called. Anything about C++ can be probably misused in the hands of the inexperienced.

Other than that, I think this is a good move, and it'll be interesting to see how this develops. There probably are a lot of (heavy) opinions on this inside the GCC community, and it it'll be interesting to see which directions they choose to go.

throwing an exception in the constructor comes to mind

I don't know C++ and thus don't know all the different ways to break constructors and destructors, but this particular way will be banned-- exceptions are off-limits.

I kind of think that the worst part of all of this will not be the C++ code that is added to gcc, but the massive bikeshedding that looks to be inevitable at the start.

Yes, that would indeed be the case if they compiled with -fno-exceptions, which they just might do indeed, - otherwise, you can still cause exceptions to be thrown without using them yourself (for example, if you're out of memory, 'new Foo ()' causes a std::bad_alloc () exception to be thrown).

And yes, I feel for the people in the GCC community that have to lead the team through this process of coming up with an acceptable policy most people agree with. I'm pretty sure it will be a challenging task with lots of egos colliding.

Why wouldn't a compiler just abort if it runs out of memory? A compiler seems to be a short running program -- I wouldn't even bother too much freeing up allocated memory.

    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  19087 scschnei  25   0  412m 333m 5480 R  100 16.6   0:07.62 cc1plus

Your C++ compiler would be unusable for some modern C++ programs. You're judging how you expect a compiler to behave based on how you've used them in the past. C++ with heavy template meta-programming (like what I was compiling there) can take an enormous amount of memory and CPU time to finish.

Interesting indeed. It's good that GCC people start eating their own dog food and allow the use of C++. I'm sure this move will bring improvements to g++.

And if they have any issues, they could start compiling GCC with LLVM. I hear Clang's implementation of C++ is pretty fast, and it could help track down bugs in both suites.

That is, assuming that GCC doesn't use a ton of GCC-specific extensions, which I'm fairly certain they do.

throwing an exception in the constructor comes to mind, in which case the destructor isn't called

Of course it is not called -- the object has failed to construct. There is no object. You cannot call a destructor on nothing. Now if some data member has been constructed but the call constructor failed, destructors for such members will be called.

The constructor might be partially executed before the exception is thrown (for example, allocated memory or locked resources), in which case those things don't get cleaned up.

I'm not arguing it isn't correct behavior, it's just that things don't always seem as easy and straightforward as they look on first sight.

So don't use exceptions. They're not needed and definitely make C++ code far more complicated, not less.

Yes, they just allowed it. They're not going to rewrite gcc in C++.

But still, why, oh why?

Eventhough C++ allows, in some cases, the possibility to use easier syntax for certain constructs, it's not particularly more expressive language than C. I don't know gcc codebase but if they decided to actually reimplement something in C++, it would take a lot of time just to make it comparable to the current C implementation.

While something like a Haskell/OCaml implementation would probably be too cutting-edge, considering the conservative inertia of such a big project, I wonder why they didn't consider some high-level language better suited for compiler writing.

For a project like gcc, even designing a domain specific compiler-writing-language wouldn't be too far fetched given the limited problem domain and the big yields that a finely targeted language might give.

Every time I start a project in C, I end up switching to c-style C++ when I realize that I'd really like a standard library of type-safe containers.

...because large-scale C projects end up reinventing C++ features in a more complicated, error-prone way.

C++ is much more expressive than C. It can compete on equal terms with other high-level OO languages, it has some functional features and it contains all of C. On the downside, it's difficult to learn and takes much time to become proficient in.

Once you become proficient there's no contest.

because large-scale C projects end up reinventing C++ features in a more complicated, error-prone way

You are spot on. Here is an excerpt from a blog post on writing a GCC plugin:

The GCC AST itself is a curious data structure in that it is an implementation of the polymorphic data type idea in C (next time someone tells you that polymorphism works perfectly in C and they don’t need “bloated” C++ for that, show them the GCC AST). The base “handle” for all the AST nodes is the tree pointer type. Because the actual nodes can be of some “extended” types, access to the data stored in the AST nodes is done via macros. All such macros are spelled in capital letters and normally perform two operations: they check that the actual node type is compatible with the request and, if so, they return the data requested.

http://www.codesynthesis.com/~boris/blog/2010/05/10/parsing-...

It takes some overhead to implement the most essential C++ stuff in a C project. After that, the expressibility of these two languages effectively converge. That is, the will be differing factors but those factors won't be an order-of-magnitude different.

Hence, it would make sense to start with C++ in the first place, if only possible, because you will immediately save some months of C coding. However, on any large project the overhead becomes negligible. For example, gcc already has the C codebase written for decades.

The new allowed development language ought to offer not only more power but a lot more power.

While something like a Haskell/OCaml implementation would probably be too cutting-edge, considering the conservative inertia of such a big project, I wonder why they didn't consider some high-level language better suited for compiler writing.

I imagine bootstrapping could be a problem. If GHC needs a C compiler to build itself, and the C compiler needs GHC to build itself, you'll need a good, very portable C compiler to get started - that's GCC. Cross-compiling could perhaps be an option, although GHC doesn't support it for the moment.

Using C++ doesn't require throwing out almost a quarter decade's worth of code.

Perhaps you mean a quarter century?

Oops... Yes, I did. :-)

When I read this stuff, like what to ban, what to allow and so forth, it's impossible for me to avoid thinking that actually C++, Objective-C, and D, are not enough. We are still in a world where a "better C" is needed as the available choices are not good enough.

Out of curiosity, how did you lump Objective-C and D into this. I haven't heard of people banning the use features of Objective-C and D like they do with C++.

//well, except where the platform doesn't support the feature (e.g. iPhone::Garbage Collection).

I don't think the reasons are the same. C++ is too complex, and while it's true that exploiting advanced features it's possible to do a great deal of things, it's not hard to imagine an object system for C much simpler and still able to achieve most of the benefits.

I think Objective-C is taken alive by the fact that Apple is pushing it forward, IMHO this is already telling enough about it. A few things are nice but it's too verbose, the syntax is not nice, some semantic is tricky (memory management is confusing for newcomers), and I feel in it a strange mix of high level features with other things that are too low level or not well conceived (like @synthesize).

D has other problems (like two different flavors and other stuff related to the fact it's pretty recent) but I think it does not qualify as the "better C" that can really be accepted in short time, as the difference with C is too strong and it's not a strict superset of C.

What I think it's needed is a C with classes without fancy features and with a solid standard library that makes good use of the new OOP stuff. The layer that's enough to avoid to write structures and function pointers to fake objects, just that tiny layer, but done right. Not claiming this is easy at all, but probably there are very little people interested in solving this problem right now.

I think Go might become a viable alternative to C for systems programming.

I think that one of the requirements that makes Go unsuitable as a C replacement in this specific case is the presence of the garbage collector. We need a language that we could use to write the garbage collector itself. It has to be a non-GC'd language or at least allow you to use it without linking to the GC.

I can see that being a problem if you were writing a garbage collector, but that's not a problem in this particular case (a C/C++ compiler).

This could be really great for GCC if they pick the right subset.

For instance, I could imagine that a GCC that takes advantage of namespaces, overloaded functions, and template functions (notably: not classes, exceptions, or implicit type coersion) to be quite a lot easier to understand than today's deeply preprocessor-dependent GCC.

It's easy to assume that C++ implies OO, but you really don't need to go that way, and you might not want to if you're starting with a project as old and hardened as GCC.

I've heard anecdotal reports from a few developers that OS X's IOKit driver framework, and its limited subset of C++, works very well. It's very limited in terms of the language features available, and sounds like it strikes a good balance.

Of course, this is all anecdotal. YMMV.

"Both C and Lisp will be available as system programming languages." - From the GNU manifesto

Maybe just implement GCC in Lisp? Or am I just nitpicking?

All of the machine descriptions are written in Lisp. See gcc/config/i386.md for an example.

AFAIK gcc is not the best designed program in the world (I just compiled it once, and to me it seemed to be a huge bunch of patches over patches).

At the same time I know C++ enough to consider it extremely error-prone, expecially if not managed correctly!

Put together the two things and ...maybe it's time to have a look to some other compiler. What about TCC? :P

...or LLVM :-P

http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine

"The Low Level Virtual Machine (LLVM) is a compiler infrastructure, written in C++, which is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages. "

I am hoping LLVM / clang actually give GCC some competition. I like the direction of using the same code for the compiler in tools.

"Before we start to actually use C++, we need to determine a set of coding standards that will apply to use of C++ within GCC."

So we have another two months of bike shedding right here.

An interesting metric for this is if the resulting code is smaller. Wouldn't we expect that to be the case using a higher-level language?

For those who don't know it: http://yosefk.com/c++fqa/

Very interesting read about the problems of C++.

Reply on news.ycombinator.com