Hacker News Reader

Comment by yason | Hacker News Reader

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.

View on HN

...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.

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.

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. :-)

Reply on news.ycombinator.com