通过C/C+编译+；和编译器错误/限制 我正在研究通过C（或者如果可能的异常结果足够有用）编译C（或者可能是C++）的高级语言（Lisp like）的可能性。这是许多项目以前使用过的策略。当然，这将生成与手工编写的任何代码不同的C代码，并且可能在某些方面超过了其复杂性

现代C编译器在正常使用情况下是高度可靠的，但很难知道在异常压力下边缘情况下可能隐藏着什么bug，特别是如果你仔细检查一些“没有程序员会写出大于Y的X”隐藏限制

我突然想到，这些事实的巧合可能会导致不幸

---

是否有任何已知的情况，或者有一个很好的方法来发现生成的代码，在编译的编译器（例如GCC、微软C++、Clang）的合理的最近版本的边缘案例错误/限制中跳闸？

< P>这听起来可能是显而易见的，但是真正知道的唯一方法是通过测试。如果你不能自己做所有的努力，至少让你的产品跨平台，这样人们就可以轻松地为你测试！如果人们喜欢你的项目，他们通常愿意免费提交bug报告甚至补丁：）

简短回答：

如果您需要编译器的性能而不是解释器（或预编译器+解释器）的易用性，那么您别无选择。你将编译成一些低级语言，C是当今的汇编语言，C++是可用的，并且作为C任务的合适工具，你没有理由害怕这个路线。从某种意义上说，这实际上是一条非常常见的路线

长答案：

生成的代码绝非异常。即使是对生成代码的相对温和的使用，也会导致C源代码在数量（以微小的变化重复数百万次的琐碎代码模式）或质量（人类永远不会使用但仍然是合法的C++的语言特性的组合）方面“不同于任何程序员编写的代码”。也有不少编译器编译成C或C++，并且对编写C和C++语言标准的人来说是众所周知的。 <>最常见的C和C++编译器很好地处理生成的代码。是的，它们从来都不是完美的

• 编译器可能有各种简单的限制，例如最大代码行数 长度；一旦您遇到这些问题，这些问题往往会被记录在案，并且很容易在生成器中得到遵守
• 编译器可能有缺陷。
  • 与手工编写的代码相比，生成的代码实际上不太关心某些类型的缺陷。一旦您开始理解模式并关心问题，您的代码生成器实际上为您提供了一定程度的自由，可以系统地处理许多情况
  • 只要有足够的编译器用户，就会很快发现导致编译器无法正确编译有效代码的缺陷。编译器供应商将它们视为特别高优先级的缺陷。即使编译器基本上已经死了，或者服务于一个利基市场，因此没有可用的修复程序，互联网上也会有大量信息，包括人们现有的解决缺陷的经验（不同的编译器，不同的代码结构，不同的编译器开关…解决方案变化很大，可能会感到尴尬，但没有人会因为某些软件有缺陷而放弃工作，对吧）？因此通常有可搜索解决方案的选择

通常是为了在编译器上实现可移植性，但也知道和跟踪可移植性的限制。如果你没有很好地测试一个特定的C或C++编译器，不要声称它将作为你的工具集的一部分。

---

你问C和C++之间的隐含问题。这里有更多的灰色。C++是一种非常丰富的语言。你可以在你的生成器中使用几乎所有C++特性来达到好的目的，但是在某些情况下，你应该问问自己，某个特定的主要特征是否会成为一个负担，比它给你带来的代价更大。。例如，不同的编译器使用不同的模板实例化策略。隐式实例化可能会导致可移植生成代码的不可预见的复杂性。如果模板确实能极大地帮助您设计生成器，请毫不犹豫地使用它们；但如果您对它们只有一个边际用例，请记住您有一个更好的解决方案这可能不是你想要的答案，但几年前，我在一个项目中工作，系统的一部分是用某种更高级的语言编写的，在这个项目中，很容易在进程中构建状态机。这种语言产生了当时的C代码编译。我们在这个项目中使用的编译器是gcc（2.95左右的版本-请不要引用我的话，但肯定是3.0之前）。我们确实遇到了一些代码生成错误，但从我的记忆来看，这与使用不太流行的处理器有关[透露哪个处理器可能会透露项目中我不应该透露的内容，因此我宁愿不说它是什么，即使它是很久以前的事了]

我身边的一位同事正在调查其中一个代码生成错误，该错误存在于一个大约200k行的函数中，所有函数都是一个大的switch语句，switch语句中的每一个案例都大约有50-1000行（其中有几层子switch语句）

从我的记忆来看，代码崩溃是因为它产生了一个无效的操作，或者在一个寄存器中存储了一些已经被其他东西占用的东西，所以一旦你找到了正确的代码位，它就会因为非法的内存访问而失败，而这与代码的长大小无关，因为我的同事设法将它降到最低大约30