确实有这样一个工具，Comeau的C++编译器。 。 它将生成您无法手动维护的 C 代码，但这没有问题。 您将维护 C++ 代码，并即时转换为 C。
There is indeed such a tool, Comeau's C++ compiler. . It will generate C code which you can't manually maintain, but that's no problem. You'll maintain the C++ code, and just convert to C on the fly.
It handles some code, but will fail for more complex implementations as it hasn't been fully updated for some of the modern C++ conventions. So try compiling your code frequently until you get a feel for what's allowed.
Usage sytax from the command line is as follows for version 9.0.1:
Note that it creates a GNU flavor of C and not true ANSI C. You will want to test that this is useful for you before you invest too heavily in your code. For example, some embedded systems only accept ANSI C.
Also note that it generates functional but fairly unreadable code. I recommend commenting and maintain your C++ code and not worrying about the final C code.
EDIT : although official support of this functionality was removed, but users can still use this unofficial support from Julia language devs, to achieve mentioned above functionality.
虽然您可以在 C 中进行面向对象（例如，通过向方法添加 theType *this 第一个参数，并手动处理诸如虚表之类的多态性），但这作为设计从来都不是特别令人满意，而且看起来很丑（即使有一些预处理器黑客）。
我建议至少考虑重新设计以比较其效果。
总体而言，很大程度上取决于关键问题的答案：如果您有可用的 C++ 代码，为什么需要 C？
While you can do OO in C (e.g. by adding a theType *this first parameter to methods, and manually handling something like vtables for polymorphism) this is never particularly satisfactory as a design, and will look ugly (even with some pre-processor hacks).
I would suggest at least looking at a re-design to compare how this would work out.
Overall a lot depends on the answer to the key question: if you have working C++ code, why do you want C instead?
编译器由两个主要块组成：“前端”和“后端”。 编译器的前端分析源代码并构建所述源代码的某种形式的“中间表示”，该源代码比源代码更容易通过机器算法进行分析（即，而源代码，例如 C++ 被设计为帮助人类程序员编写代码，中间形式旨在帮助简化分析所述中间形式的算法（更容易）。 编译器的后端采用中间形式，然后将其转换为“目标语言”。
PS 据我所知，GNU 没有这样的 C++ 到 C 编译器，这完全打败了我（如果我是对的）。 因为 C 语言相当小，而且它的内部机制也相当初级，所以 C 编译器需要大约一个人年的工作（我可以第一手告诉你，因为我自己可能几年前编写了这样一个编译器，它产生了 [虚拟]堆栈机中间代码），并且能够拥有一个维护的、最新的 C++ 编译器，同时只需编写一次 C 编译器，这将是一件很棒的事情......
A compiler consists of two major blocks: the 'front end' and the 'back end'. The front end of a compiler analyzes the source code and builds some form of a 'intermediary representation' of said source code which is much easier to analyze by a machine algorithm than is the source code (i.e. whereas the source code e.g. C++ is designed to help the human programmer to write code, the intermediary form is designed to help simplify the algorithm that analyzes said intermediary form easier). The back end of a compiler takes the intermediary form and then converts it to a 'target language'.
Now, the target language for general-use compilers are assembler languages for various processors, but there's nothing to prohibit a compiler back end to produce code in some other language, for as long as said target language is (at least) as flexible as a general CPU assembler.
Now, as you can probably imagine, C is definitely as flexible as a CPU's assembler, such that a C++ to C compiler is really no problem to implement from a technical pov.
So you have: C++ ---frontEnd---> someIntermediaryForm ---backEnd---> C
You may want to check these guys out: http://www.edg.com/index.php?location=c_frontend (the above link is just informative for what can be done, they license their front ends for tens of thousands of dollars)
PS As far as i know, there is no such a C++ to C compiler by GNU, and this totally beats me (if i'm right about this). Because the C language is fairly small and it's internal mechanisms are fairly rudimentary, a C compiler requires something like one man-year work (i can tell you this first hand cause i wrote such a compiler myself may years ago, and it produces a [virtual] stack machine intermediary code), and being able to have a maintained, up-to-date C++ compiler while only having to write a C compiler once would be a great thing to have...
这是一个旧线程，但显然 C++ Faq 有一个 部分（2013 年存档版本） 对此。 如果联系作者，这显然会更新，因此从长远来看这可能会更新，但这是当前版本：
取决于你的意思。 如果您的意思是，是否可以将 C++ 转换为可读且可维护的 C 代码？ 那么抱歉，答案是否定的 - C++ 功能不会直接映射到 C，而且生成的 C 代码也不适合人类遵循。 如果您的意思是，是否有编译器将 C++ 转换为 C，以便编译到尚未有 C++ 编译器的平台上？ 那么你很幸运——继续阅读。
将 C++ 编译为 C 的编译器会对程序进行完整的语法和语义检查，并且恰好使用 C 代码作为生成目标代码的方式。 这样的编译器不仅仅是某种奇特的宏处理器。 （请不要给我发电子邮件声称这些是预处理器 - 它们不是 - 它们是完整的编译器。）可以通过转换为 C 来实现 ISO 标准 C++ 的所有功能，并且除了异常处理之外，通常会产生以下结果：目标代码的效率与传统 C++ 编译器生成的代码相当。
与流行的神话相反，在撰写本文时，还没有将 C++ 转换为 C 的 g++ 版本。这样的事情似乎是可行的，但我不知道有人实际上已经做到了（还）。
请注意，您通常需要指定目标平台的 CPU、操作系统和 C 编译器，以便生成的 C 代码专门针对该平台。 这意味着： (a) 您可能无法获取为平台 X 生成的 C 代码并在平台 Y 上编译它； (b) 自己翻译会很困难 - 使用这些工具之一可能会更便宜/更安全。
再说一遍：不要给我发电子邮件说这些只是预处理器 - 它们不是 - 它们是编译器。
This is an old thread but apparently the C++ Faq has a section(Archived 2013 version) on this. This apparently will be updated if the author is contacted so this will probably be more up to date in the long run, but here is the current version:
Depends on what you mean. If you mean, Is it possible to convert C++ to readable and maintainable C-code? then sorry, the answer is No — C++ features don't directly map to C, plus the generated C code is not intended for humans to follow. If instead you mean, Are there compilers which convert C++ to C for the purpose of compiling onto a platform that yet doesn't have a C++ compiler? then you're in luck — keep reading.
A compiler which compiles C++ to C does full syntax and semantic checking on the program, and just happens to use C code as a way of generating object code. Such a compiler is not merely some kind of fancy macro processor. (And please don't email me claiming these are preprocessors — they are not — they are full compilers.) It is possible to implement all of the features of ISO Standard C++ by translation to C, and except for exception handling, it typically results in object code with efficiency comparable to that of the code generated by a conventional C++ compiler.
Here are some products that perform compilation to C:
Cfront, the original implementation of C++, done by Bjarne Stroustrup and others at AT&T, generates C code. However it has two problems: it's been difficult to obtain a license since the mid 90s when it started going through a maze of ownership changes, and development ceased at that same time and so it doesn't get bug fixes and doesn't support any of the newer language features (e.g., exceptions, namespaces, RTTI, member templates).
Contrary to popular myth, as of this writing there is no version of g++ that translates C++ to C. Such a thing seems to be doable, but I am not aware that anyone has actually done it (yet).
Note that you typically need to specify the target platform's CPU, OS and C compiler so that the generated C code will be specifically targeted for this platform. This means: (a) you probably can't take the C code generated for platform X and compile it on platform Y; and (b) it'll be difficult to do the translation yourself — it'll probably be a lot cheaper/safer with one of these tools.
One more time: do not email me saying these are just preprocessors — they are not — they are compilers.
发布评论
评论（6）
确实有这样一个工具，Comeau的C++编译器。 。 它将生成您无法手动维护的 C 代码，但这没有问题。 您将维护 C++ 代码，并即时转换为 C。
There is indeed such a tool, Comeau's C++ compiler. . It will generate C code which you can't manually maintain, but that's no problem. You'll maintain the C++ code, and just convert to C on the fly.
http://llvm.org/docs/FAQ.html#translatecxx
它处理一些代码，但对于更复杂的实现将会失败，因为它尚未针对某些现代 C++ 约定进行完全更新。 因此，请尝试经常编译代码，直到您了解允许的内容。
对于版本 9.0.1，命令行的使用语法如下：
对于旧版本（不确定过渡版本），请使用以下语法：
请注意，它创建了 GNU 风格的 C，而不是真正的 ANSI C。您将需要测试在您对代码投入过多之前，这对您很有用。 例如，某些嵌入式系统仅接受 ANSI C。
另请注意，它会生成功能正常但相当不可读的代码。 我建议注释并维护您的 C++ 代码，而不用担心最终的 C 代码。
编辑：虽然删除了对此功能的官方支持，但用户仍然可以使用 Julia 的此非官方支持语言开发人员，实现上述功能。
http://llvm.org/docs/FAQ.html#translatecxx
It handles some code, but will fail for more complex implementations as it hasn't been fully updated for some of the modern C++ conventions. So try compiling your code frequently until you get a feel for what's allowed.
Usage sytax from the command line is as follows for version 9.0.1:
For older versions (unsure of transition version), use the following syntax:
Note that it creates a GNU flavor of C and not true ANSI C. You will want to test that this is useful for you before you invest too heavily in your code. For example, some embedded systems only accept ANSI C.
Also note that it generates functional but fairly unreadable code. I recommend commenting and maintain your C++ code and not worrying about the final C code.
EDIT : although official support of this functionality was removed, but users can still use this unofficial support from Julia language devs, to achieve mentioned above functionality.
虽然您可以在 C 中进行面向对象（例如，通过向方法添加
theType *this第一个参数，并手动处理诸如虚表之类的多态性），但这作为设计从来都不是特别令人满意，而且看起来很丑（即使有一些预处理器黑客）。我建议至少考虑重新设计以比较其效果。
总体而言，很大程度上取决于关键问题的答案：如果您有可用的 C++ 代码，为什么需要 C？
While you can do OO in C (e.g. by adding a
theType *thisfirst parameter to methods, and manually handling something like vtables for polymorphism) this is never particularly satisfactory as a design, and will look ugly (even with some pre-processor hacks).I would suggest at least looking at a re-design to compare how this would work out.
Overall a lot depends on the answer to the key question: if you have working C++ code, why do you want C instead?
也许好的 cfront 可以吗？
Maybe good ol' cfront will do?
编译器由两个主要块组成：“前端”和“后端”。
编译器的前端分析源代码并构建所述源代码的某种形式的“中间表示”，该源代码比源代码更容易通过机器算法进行分析（即，而源代码，例如 C++ 被设计为帮助人类程序员编写代码，中间形式旨在帮助简化分析所述中间形式的算法（更容易）。
编译器的后端采用中间形式，然后将其转换为“目标语言”。
现在，通用编译器的目标语言是用于各种处理器的汇编语言，但是没有什么可以禁止编译器后端以其他语言生成代码，只要所述目标语言（至少）与通用CPU汇编器。
现在，正如您可能想象的那样，C 绝对与 CPU 的汇编器一样灵活，因此从技术角度来看，实现 C++ 到 C 的编译器确实没有问题。
所以你有：C++ ---frontEnd---> someIntermediaryForm ---backEnd---> C
您可能想看看这些人： http://www.edg.com/index .php?location=c_frontend
（上面的链接只是提供了可以可以做什么的信息，他们以数万美元的价格授权其前端）
PS
据我所知，GNU 没有这样的 C++ 到 C 编译器，这完全打败了我（如果我是对的）。 因为 C 语言相当小，而且它的内部机制也相当初级，所以 C 编译器需要大约一个人年的工作（我可以第一手告诉你，因为我自己可能几年前编写了这样一个编译器，它产生了 [虚拟]堆栈机中间代码），并且能够拥有一个维护的、最新的 C++ 编译器，同时只需编写一次 C 编译器，这将是一件很棒的事情......
A compiler consists of two major blocks: the 'front end' and the 'back end'.
The front end of a compiler analyzes the source code and builds some form of a 'intermediary representation' of said source code which is much easier to analyze by a machine algorithm than is the source code (i.e. whereas the source code e.g. C++ is designed to help the human programmer to write code, the intermediary form is designed to help simplify the algorithm that analyzes said intermediary form easier).
The back end of a compiler takes the intermediary form and then converts it to a 'target language'.
Now, the target language for general-use compilers are assembler languages for various processors, but there's nothing to prohibit a compiler back end to produce code in some other language, for as long as said target language is (at least) as flexible as a general CPU assembler.
Now, as you can probably imagine, C is definitely as flexible as a CPU's assembler, such that a C++ to C compiler is really no problem to implement from a technical pov.
So you have: C++ ---frontEnd---> someIntermediaryForm ---backEnd---> C
You may want to check these guys out: http://www.edg.com/index.php?location=c_frontend
(the above link is just informative for what can be done, they license their front ends for tens of thousands of dollars)
PS
As far as i know, there is no such a C++ to C compiler by GNU, and this totally beats me (if i'm right about this). Because the C language is fairly small and it's internal mechanisms are fairly rudimentary, a C compiler requires something like one man-year work (i can tell you this first hand cause i wrote such a compiler myself may years ago, and it produces a [virtual] stack machine intermediary code), and being able to have a maintained, up-to-date C++ compiler while only having to write a C compiler once would be a great thing to have...
这是一个旧线程，但显然
C++ Faq有一个 部分 （2013 年存档版本） 对此。 如果联系作者，这显然会更新，因此从长远来看这可能会更新，但这是当前版本：This is an old thread but apparently the
C++ Faqhas a section (Archived 2013 version) on this. This apparently will be updated if the author is contacted so this will probably be more up to date in the long run, but here is the current version: