

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer

I was wondering why C++ is a good choice to write a compiler. Of course C is good for this purpose too, because many compilers are written either in C or C++ but I am more interested in C++ this time. Any good reasons ? I was looking for that in the Internet, but I cannot find any good reasons.

share|improve this question
"Many compilers are written [...] in C++" - any references? Which ones? What makes you think C++ is more often used for compiler construction than other popular languages? – Doc Brown May 26 '12 at 5:41
@DocBrown Well, Clang and MSVC are written mostly in C++, gcc have a bit of C++ in it now, Java JVM are written in C++ and also… – Klaim May 26 '12 at 7:52
@DocBrown DMD the reference compiler for D is written in C++ – ratchet freak May 26 '12 at 17:36
Who says it's a good choice?? – Phil May 26 '12 at 19:45
@Phil Do you think they made this choice without any consideration of alternatives? It's not a "good" choice, it's a "efficient" choice. – Klaim May 27 '12 at 11:34
up vote 20 down vote accepted

C++ has two sides to it. It has a low-level development side which makes it seem like a natural language for doing low level thing like code generation. It also has a high-level side (which C does not) that lets you structure a complex application (like a compiler) in a logical, object oriented way, while still maintaining performance. Because it has both the low and high level aspects to it, it's a good choice for large application which require low-level features or performance.

share|improve this answer
As far as I know a lot of the logic inside a compiler is of functional nature (transforming complex data structures into other data structures) so I am not sure if object-oriented facilities (which are more targeted to programming-in-the-large, architectural aspects) bring a real advantage to compiler construction wrt to a procedural programming style. Just my 2 cents. – Giorgio May 26 '12 at 5:36
@Giorgio Having objects helps in a lot of other aspects of compiler writing. For example, there's a lot of state a compiler has to deal with when optimizing and that kind of stuff lends itself well to OOP. Also, OOP and Functional programming can be quite complimentary, so just because the algorithms might be mostly functional, doesn't mean that objects won't help. – Oleksi May 26 '12 at 5:39
@Giorgio and Oleksi: I can confirm both of you. I wrote a compiler with Haskell for a real world language. It was a really good fit. But sometimes I missed some OO around. If I had to write another compiler I'd definitely choose Haskell, but this is really a special case. I would not choose Haskell without hesitation for other types of projects. – scarfridge May 26 '12 at 7:19
Why do you need to have a language with a "low-level side" to do code generation? I can't see how these two are connected in any way. – phant0m May 26 '12 at 8:52
You don't need a "low-level side" to do code generation any more than you need Unicode identifiers to be able to write Japanese text to a file. – dan04 May 26 '12 at 16:05

My experience does not agree with your premise here. In fact, for high-level general-purpose languages, it is a very common practice to write the compiler in the same language as the source language (the language being compiled). For example:

  • Sun's Java compiler is written in Java
  • The Scala compiler is written in Scala
  • Mono's C# compiler is written in C#
  • Squick's Smalltalk compiler is written in Smalltalk
  • ... and many more

An exception is compiler front-ends written for existing compiler frameworks, such as GCC, LLVM or Polyglot, which are then written in the framework's language, or compilers that rely on existing parser generators such as Yacc. Since GCC, LLVM and Yacc are common, established tools written in C and C++, it gives an incentive to compiler writers to use them, which might lead to C and C++ getting a large share in the compiler implementation language distribution.

share|improve this answer
I think that has much more to do with the people writing the compiler knowing well and liking a lot the language they are writing a compiler for than for objective technical reasons. – Andreas Bonini May 26 '12 at 18:40
@Krelp I agree it's not about an objective technical reason, but it's not really "liking", either - it's just considered some rite of passage for a language - "is it mature enough to be able to serve as the implementation language of its own compiler". – Oak May 26 '12 at 18:44
Sun's Java compiler is written in C++: – Klaim May 27 '12 at 11:36
@Klaim you are confusing two products here. One is Sun's Java compiler (javac command-line), which compiles Java to Java Bytecode. It is written in Java - I have modified it many times myself and you can browse its Java sources online. The other is the just-in-time compiler embedded in the Hotspot JVM, which compiles Java Bytecode to native machine code. Like most of the JVM it's written in C++, but it's not a Java compiler - in fact, it knows nothing about the Java language. – Oak May 27 '12 at 12:17
@Oak Interesting, thanks for the clarification. – Klaim May 27 '12 at 12:52

I tend to question the basic premise here. While C and C++ work perfectly well for writing compilers, quite a few other languages seem to work perfectly well for the task as well.

A bit depends on the language you're compiling though. For small, simple languages, C and Pascal work quite nicely. If you're going to compile something big and complex, your compiler gets big and complex too -- in which case, C++'s extra features for organizing and working with larger programs obviously come in handy. That isn't really very specific to compiling though, just features useful for larger programs in general.

I think it's also worth mentioning one other point. Beginners (seem to) think of compilers as mostly doing text manipulation, so they think something like Perl will be a massive help in writing compilers. In reality, most of the interesting parts of compilation don't really start until after you've built your AST. While I'm sure Perl can do the job perfectly well, its text manipulation capability doesn't really give it a huge advantage either (text manipulation is mostly in the lexer, and lexer generators for things like C all support REs anyway).

share|improve this answer
AST = Abstract Syntax Tree, RE = Regular Expressions – chaotic3quilibrium May 29 '12 at 14:50

Compilers may be implemented in any modern language. However, one of the most important requirements from a compiler is to be fast.

C++ has a clear advantage here. Optimization in C++ does not come cheap. However, due the the low-level nature of this language, it is possible to manually optimize C++ code more than in any other language (except Assembly which is not portable).

share|improve this answer
Another important requirement is for the code generated to be correct - I'd rather have a slow compiler I can trust than a fast one which generates incorrect code. – user1249 May 26 '12 at 10:24
While it is certainly possible to optimize C++ very heavily, there's a lot of rather… well… less than optimal C++ code out there. – Donal Fellows May 26 '12 at 18:29
@DonalFellows Turn it the other way around: it is possible to write less than optimal code in any language, but there are optimizations that are impossible to enable in other languages than C++ (other than Assembler. I don't include C because of lack of high level structures allowing stronger inlining). – Klaim May 27 '12 at 15:30

To compile what to what? A compiler transforms a source code from one language (source language) to another (destination language), which doesn't indicate anything about the low-levelness of the destination language.

  • CoffeeScript compiles to JavaScript, the compiler being written in CoffeeScript.
  • Script# compiles C# into JavaScript, the compiler being written in, if I remember well, C#.
  • etc.

The language you pick to write a compiler depends on the context. For example, working on a project which compiles a language derived from PHP to a native PHP code, I used a mix of PHP and C# to write the compiler, because it made the most sense for me given my skills. Another person would pick Python, or Java and PHP, or C++ with a bit of JavaScript, or whatsoever.

C or C++ is a popular choice because of the support of compiler related tools (see the answer by Telastyn), and because those two languages allow you to go really native. But there is nothing wrong in choosing another language.

Note that in order to be more geeky, you may pick the source language to write the compiler itself. It's what happened for CoffeeScript compiler and many other compilers. It is also popular with the IDEs: one of the first Visual Studio was built using the same Visual Studio.

share|improve this answer
Self-hosting is not geeky, it is an important property for porting a compiler. – user1249 May 26 '12 at 8:49
The reason is, that it immediately enables the compiler itself to be a test program. It will most likely also be the largest program for that compiler for quite a while. – user1249 May 26 '12 at 10:27

I suspect that the prime motivator for their use is that Lex/Yacc/Bison output is (primarily) in C. Since that's been the standard for so long, it has momentum.

Not that those are particularly good reasons...

share|improve this answer
Actually it doesn't satisfy me, but thanks for try. – Kobra May 26 '12 at 5:23
That does not answer the question "why to choose C++ over C for compiler construction". – Doc Brown May 26 '12 at 5:43
It's not a good reason at all. Analogous tools to Lex and Yacc exist for many platforms. PLY and ANTLR, for example. – user16764 May 26 '12 at 5:58
Moreover, most popular real-world compilers (I'm pretty certain abuot Clang and GCC, for instance) use hand-written parsers. – delnan May 26 '12 at 8:55
@delnan: Yes but they probably started off using a generated one to get things off the ground. The hand generation of the parser is an optimization step you don't really want to do until you can prove other things are working. – Loki Astari May 27 '12 at 1:43

Your Answer


