大型嵌入式公司是否"forced"使用旧的编程标准/编译器？

我对嵌入式领域了解不多，但其他一些使用c++的公司使用旧的硬件/平台

---

这真的取决于他们使用的公司和平台。但是，通过一些努力和开放的管理，应该没有什么反对现代c++无处不在(从技术的角度来看)

我知道有几家公司的开发人员鼓励向现代c++迁移，而且越来越多。

有时候你必须付出更多的努力，而不仅仅是安装一个新的编译器。当你需要交付到一个旧的平台(例如Debian 6)并且不能更改操作系统时，你必须在该平台上手动编译libstdc++，并将其与你的产品一起交付/让它使用特定的平台(有更多的细节，但你明白了)。

---

因此，可能有些公司因为保守的管理或开发人员不关心现代c++而坚持使用旧的c++。升级换代的公司也越来越多。而且学习现代c++也没有错，因为在使用现代c++的公司里，"旧"风格通常是不被鼓励的。

---

当他们切换编译器时，代码可能会"中断"，但只是在编译级别，因为他们使用了非标准的特性/语法(一些旧的编译器更宽容)。但是行为方面，我不知道有什么东西会"默默地"破坏(标准委员会在每次更改时都积极地试图避免这种情况)，并且您还可以通过更好的编译器获得更多更好的警告。

大公司的产品不需要来自单一的代码库。代码库可能依赖于许多其他库(包括第三方库)。

产品代码不能用最新的编译器编译，除非它的所有依赖项都使用该版本的编译器编译。(至少静态库是这样的)

所以一般来说，对于具有大量依赖关系的大型产品，很难迁移到最新版本的编译器。此外，在迁移到最新的编译器之后，应该会产生很大的测试开销。

管理层只有在ROI(投资回报率)良好的情况下才会同意执行上述操作，而遗留代码很少这样做。

这取决于公司，他们的嵌入式产品线和他们的客户群。

有些公司有根深蒂固的文化，所以他们坚持使用旧的技术，即使面对合理的技术论据也要更新。一些公司是进步的，只要有意义，就支持更新到新的编译器和标准(相反，在有意义的时候，也支持坚持使用旧的技术)。有些公司执意要采用最新趋势，以致使用未经证实的技术，从而损害了其产品线的稳定性。

一些嵌入式产品使用不再生产的特定硬件组件，并且没有通过新硬件或软件的组合提供的具有成本效益的替代品。例如，对于硬实时系统，可能存在满足关键时间约束的旧硬件，但无法轻易获得满足原始要求的新硬件。

一些嵌入式产品是高度关键的(安全关键、任务关键等)，有一个积极的监管机构，坚持在批准更新之前提供大量可靠的技术证据(如果在没有文件证据的情况下签署这种更新的代表将承担法律责任，如果在现场出现问题-例如系统因定时错误而导致人员死亡)。这种文档的制作成本可能非常高。拥有此类产品的公司可能会发现，坚持使用旧的(被监管机构接受的)开发环境更具成本效益。为了证明更新到一个新的编译器是合理的，必须支付几百万美元，这往往会使公司不愿意为提供新的证据来证明使用新的编译器是合理的。

最终，为了销售产品，有必要说服付费的客户为它付钱。如果老系统的很大一部分客户不愿意为更新付费——毕竟，现有系统工作得很好——那么供应商就没有理由进行更新——除非他们能够使更改对客户来说成本中立(这在更新关键的嵌入式系统时通常很难实现，除非供应商愿意承担大量成本)。类似地，关键客户可能实际上已经为现有系统的开发和维护支付了费用，并且可能认为继续为现有系统的维护支付费用比为更新支付费用更物有所值，并按照要求提供证据。

就在今年，我使用了两个超过20年的不同编译器。然而，这并不适用于新设计。这是为了维护同样有20年历史的产品。嵌入式产品可以支持几十年。在我的一个案例中，一个硬件组件过时了，这需要一个小的重新设计，需要一个软件更新。在另一种情况下，硬件设计必须更新以符合RoHS要求，并且由此产生的设计需要软件更新。在这两种情况下，我认为使用现代编译器会带来更多的工作和风险。旧的代码和二进制已经被20年的工作经验证明了。

在第三种情况下，微控制器过时了，我们重新设计了一个运行软处理器的FPGA。在这种情况下，需要进行一些移植，我使用了一种不同的、更现代的编译器。但是我仍然非常谨慎，我改变了多少原始的源代码。

我不会说我被政策"强迫"使用这些旧的编译器而避免新的编译器特性。当你维护旧的设计时，这可能是一个实用性的问题。或者也可以选择做更少的更改，以避免无意中破坏已经被证明有效的东西。

对于新设计，我们使用现代编译器。而且我从来没有限制自己使用旧的C标准。

PS:为了获得更苛刻的体验，你可以将自己限制在只能在Windows XP上工作的编译器和需要PC上并行端口的调试器。