c是编译语言吗,将语言编译为C是一个好主意吗？

Marco van de..

7

除了形成所有代码生成器质量的原因外,还有其他问题:

免费的C编译器(gcc,clang)有点以Unix为中心

支持多个编译器(例如Unix上的gcc和Windows上的MSVC)需要重复工作.

编译器可能会在Windows上拖动运行时库(甚至是*nix仿真),这些都很痛苦.两个不同的C运行时(例如linux libc和msvcrt)基于使您自己的运行时及其维护复杂化

您在项目中获得了一个大型外部版本blob,这意味着主要的版本转换(例如,更改损坏可能会损害您的运行时库,ABI更改,如更改对齐)可能需要相当多的工作.请注意,这适用于编译器和外部版本(部分)运行时库.并且多个编译器将其相乘.这对于C和后端来说并不是那么糟糕,但是在你直接连接(读取:下注)后端的情况下,就像是gcc/llvm前端一样.

在遵循这条道路的许多语言中,您会看到Cisms渗透到主要语言中.当然这对你不开心,但你会受到诱惑:-)

不直接映射到标准C的语言功能(如嵌套过程和其他需要堆栈摆弄的东西)很难.

请注意,第4点也意味着您需要花时间在外部项目发展时保持工作.这段时间通常不会真正进入您的项目,并且由于项目更具动态性,因此多平台版本需要大量额外的发布工程来满足变更需求.

简而言之,从我所看到的,虽然这样的举动允许快速启动(为许多架构免费获得合理的代码生成器),但也有缺点.其中大多数都与失去控制和Windows支持*gix等*nix中心项目有关.(LLVM对于长期来说太新了,但是他们的言论听起来很像十年前的gcc).如果一个你非常依赖的项目保持一定的路线(比如GCC会非常慢),那么你就会陷入困境.

首先,确定您是否希望拥有严重的非*nix(OS X更加unixy)支持,或者只有具有Windows的mingw权宜之计的Linux编译器？许多编译器需要一流的Windows支持.

第二,产品必须如何成品？什么是主要受众？它是开源开发人员可以处理DIY工具链的工具,还是想要定位初学者市场(如许多第三方产品,例如RealBasic)？

或者你真的想为深度整合和完整工具链的专业人士提供全面的产品吗？

这三个都是编译器项目的有效指示.问问自己你的主要方向是什么,并且不要假设有更多选项可以及时获得.例如,评估九十年代早期选择成为GCC前端的项目.

基本上,unix的方式是扩展(最大化平台)

完整的套件(如VS和Delphi,后者最近也开始支持OS X并且过去支持linux)深入并尝试最大化生产力.(几乎完全支持Windows平台,深度集成)

第三方项目不太明确.他们更多地追求自雇程序员和小众商店.他们拥有较少的开发人员资源,但更好地管理和关注他们.