The compiler consists of two main blocks: "front end" and "back end". The front end of the compiler analyzes the source code and creates some form of “intermediate representation” of the mentioned source code, which is much easier to parse by a machine algorithm than the source code (that is, while the source code, for example, C ++, is designed to help the programmer a person to write code, the intermediate form is intended to simplify the algorithm, which more easily analyzes the specified intermediate form) The back end of the compiler takes an intermediate form and then converts it to the "target language".
Now the target language for general purpose compilers is assembler languages for different processors, but there is nothing that could prevent the compiler from completing work on code in some other language until the specified target language is (at least) as a common processor collector .
Now, as you can imagine, C is definitely as flexible as the CPU assembler, so the C ++ to C compiler is really not a problem to implement from a technical point of view.
So you have: C ++ --- frontEnd ---> someIntermediaryForm --- backEnd ---> C
You can check out these guys: http://www.edg.com/index.php?location=c_frontend (the link above is just informative for what you can do, they license their front ends for tens of thousands of dollars).
PS As far as I know, there is no such C ++ compiler for C GNU, and it completely beats me (if I'm right about this). Since the C-language is quite small and the internal mechanisms are rather rudimentary, the C compiler requires something like one man-year of work (I can tell you that I wrote this compiler myself a few years ago and it creates [virtual] stack intermediate code) and the ability to have a supported, updated C ++ compiler, although only writing a C compiler would one day be wonderful ...
Gyll Jan 10 '13 at 16:35 2013-01-10 16:35
source share