Hacker News Reader

Comment by WalterBright | Hacker News Reader

> There's certainly plenty of evidence that someone has read this book, since otherwise we wouldn't have so many C++ compilers to choose from.

I don't think that's quite true. The only C++ compilers I know of are:

1. cfront C++ (from which many C++ compilers were derived)

2. Digital Mars C++ (the one I wrote)

3. g++

4. clang++

5. EDG C++ (from which many other C++ compilers are derived)

6. Microsoft C++

7. Taumetric C++

It's a pretty thin list for 30 years. (I apologize if I neglected any.) Contrast that with C - at one time in the 1980s I counted over 30 of them (I'm not sure how many were independent creations).

Edit: removed Borland C++ as that was derived from Taumetric.

View on HN

Maybe Intel C++ as well? But most people who have that book didn't buy it to write a compiler. Isn't C++ ridiculously hard to write a compiler for? While I haven't written one, I think it'd be much easier to write one for C — and for that I imagine it would very nearly suffice to have the K&R book.

Every C++ front end I know of has at least 10 man years in it. I'm pretty sure it's the hardest language to implement, by far. (The core language.)

Ironically, one of the hardest things about a C compiler is the preprocessor. You'd think a text macro processor would be simple, and it should be simple. There's an amazing amount of subtle complexity in just the handful of pages describing it in the Standard.

I and many others implemented a C compiler based on K+R, and I can attest that a lot of rework can be avoided if following a Standard instead (C89 did not exist at the time).

   I'm pretty sure it's the 
   hardest language to implement

Harder than languages that require JIT compilers to achieve reasonable performance?

Even scalac and ghc are pretty complex beasts in order to Scala and Haskell reasonably speedy.

You can sink 10 years into just about any software to make it run faster. I wouldn't think that reflects on the inherent difficulty of writing a compiler in the abstract.

Sure, but a simplistic C++ compiler will still produce code of acceptable speed. The same is not true of simplistic compilers for languages like Javascript.

Meta-tracing a la PyPy is such a revolution because it enables low-cost creation of reasonably performant tracing JIT compilers.

I read the comment as saying C++ is the hardest language to implement, not the hardest language to make fast.

Speed and type-inference are the two hard things in compilation in my experience.

I've written a Java compiler, and a friend of mine (Steve Russell) wrote the JIT for it (for Symantec). It was the first JITting Java compiler, and took only a few months to complete.

Of course, I should have said "front end". Working on the optimizer/codegen is an endless process.

Yes, C++ has a baroque syntax, and I wish lexing/parsing C++ on nobody.

Their comment doesn't make sense to me. Someone working on a compiler would use the standard, right?

The book is for the people wanting to know every corner of the language. Unfortunatley I read it a long time ago and don't remember if it's enough for that purpose or one still needs Meyers and maybe some other resources.

> Someone working on a compiler would use the standard, right?

Today, yes. But in the olden days of C++, there was no standard and people used Bjarne's book.

9. Intel C++ 10. Watcom 11. IAR 12. Commeau etc.

Intel is derived from EDG. Commeau is derived from Cfront. I don't know anything about Watcom C++.

Years ago we had some banned C++ features Because they didn't compiler properly on HP-UX compiler. But maybe that was still part of the g+ umbrella

Reply on news.ycombinator.com