在嵌入式系统中应该避免 C++ 的哪些特性？
请按原因对答案进行分类，例如：
编辑：让我们使用具有 64k 内存的 ARM7TDMI 作为目标来控制答案的范围。
【问题讨论】：
RTTI 和异常处理：
模板：
虚函数和继承：
【讨论】：
选择避免某些功能应始终通过对您的软件在您的硬件上的行为进行定量分析来驱动，并选择您的工具链，在你的域需要的约束下。 C++ 开发中有很多基于迷信和古代历史而不是硬数据的传统智慧“不要做”。不幸的是，这通常会导致编写大量额外的解决方法代码，以避免使用某些人在某个地方曾经遇到过问题的功能。
【讨论】：
早期的Embedded C++ standrardRationale 读起来很有趣
在 EC++ 上也可以查看 article。
嵌入式 C++ 标准是 C++ 的一个真子集，即它没有添加。删除了以下语言功能：
在wiki page 上注意到 Bjarne Stroustrup 说（关于 EC++ 标准），“据我所知，EC++ 已死（2004 年），如果不是，它应该是。” Stroustrup 继续推荐 Prakash 的回答所引用的document。
【讨论】：
使用 ARM7 并假设您没有外部 MMU，动态内存分配问题可能更难调试。我会在指南列表中添加“明智地使用 new/delete/free/malloc”。
【讨论】：
如果您使用的是 ARM7TDMI，请不惜一切代价避免使用unaligned memory accesses。
基本的 ARM7TDMI 内核没有对齐检查，并且会在您执行未对齐读取时返回旋转数据。一些实现具有用于引发ABORT 异常的附加电路，但是如果您没有这些实现之一，则由于未对齐的访问而查找错误是非常痛苦的。
例子：
const char x[] = "ARM7TDMI";
unsigned int y = *reinterpret_cast<const unsigned int*>(&x[3]);
printf("%c%c%c%c\n", y, y>>8, y>>16, y>>24);
【讨论】：
在大多数系统中，您不希望使用 new / delete，除非您已使用从您自己的托管堆中提取的自己的实现来覆盖它们。是的，它会起作用，但你正在处理一个内存受限的系统。
【讨论】：
我不会说这有一个硬性规定；这在很大程度上取决于您的应用程序。嵌入式系统通常是：
不过，就像任何其他开发一样，您应该平衡您提到的所有要点与您获得/派生的要求。
【讨论】：
关于代码膨胀，我认为罪魁祸首可能是内联而不是模板。
例如：
// foo.h
template <typename T> void foo () { /* some relatively large definition */ }
// b1.cc
#include "foo.h"
void b1 () { foo<int> (); }
// b2.cc
#include "foo.h"
void b2 () { foo<int> (); }
// b3.cc
#include "foo.h"
void b3 () { foo<int> (); }
链接器很可能会将“foo”的所有定义合并到一个翻译单元中。因此 'foo' 的大小与任何其他命名空间函数的大小没有什么不同。
如果您的链接器不这样做，那么您可以使用显式实例化来为您执行此操作：
// foo.h
template <typename T> void foo ();
// foo.cc
#include "foo.h"
template <typename T> void foo () { /* some relatively large definition */ }
template void foo<int> (); // Definition of 'foo<int>' only in this TU
// b1.cc
#include "foo.h"
void b1 () { foo<int> (); }
// b2.cc
#include "foo.h"
void b2 () { foo<int> (); }
// b3.cc
#include "foo.h"
void b3 () { foo<int> (); }
现在考虑以下几点：
// foo.h
inline void foo () { /* some relatively large definition */ }
// b1.cc
#include "foo.h"
void b1 () { foo (); }
// b2.cc
#include "foo.h"
void b2 () { foo (); }
// b3.cc
#include "foo.h"
void b3 () { foo (); }
如果编译器决定为您内联“foo”，那么您最终将得到 3 个不同的“foo”副本。看不到模板！
编辑：来自 InSciTek Jeff 的上述评论
对你知道只会使用的函数使用显式实例化，你还可以确保删除所有未使用的函数（与非模板情况相比，这实际上可以减少代码大小）：
// a.h
template <typename T>
class A
{
public:
void f1(); // will be called
void f2(); // will be called
void f3(); // is never called
}
// a.cc
#include "a.h"
template <typename T>
void A<T>::f1 () { /* ... */ }
template <typename T>
void A<T>::f2 () { /* ... */ }
template <typename T>
void A<T>::f3 () { /* ... */ }
template void A<int>::f1 ();
template void A<int>::f2 ();
除非您的工具链完全中断，否则上述代码只会为“f1”和“f2”生成代码。
【讨论】：
时间函数通常依赖于操作系统（除非你重写它们）。使用你自己的函数（特别是如果你有一个 RTC）
只要您有足够的代码空间，就可以使用模板 - 否则不要使用它们
异常也不是很便携
不写入缓冲区的printf 函数不可移植（您需要以某种方式连接到文件系统才能使用 printf 写入 FILE*）。仅使用 sprintf、snprintf 和 str* 函数（strcat、strlen），当然还有它们的宽 char 对应函数（wcslen...）。
如果速度是问题，也许你应该使用你自己的容器而不是 STL（例如 std::map 容器来确保一个键是相等的 2 (yes 2) 与'less' 运算符（ a [less than] b == false && b [less than] a == false mean a == b ）。'less' 是 std::map 类接收的唯一比较参数（而不是仅）。这可能会导致关键例程中的一些性能损失。
模板，异常正在增加代码大小（您可以确定这一点）。有时，当代码较大时，甚至性能也会受到影响。
内存分配函数可能也需要重写，因为它们在很多方面都依赖于操作系统（尤其是在处理线程安全内存分配时）。
malloc 使用 _end 变量（通常在链接描述文件中声明）来分配内存，但这在“未知”环境中不是线程安全的。
有时您应该使用Thumb 而不是 Arm 模式。它可以提高性能。
因此，对于 64k 内存，我会说具有一些不错的特性（STL、异常等）的 C++ 可能是矫枉过正。我肯定会选择C。
【讨论】：
同时使用了 GCC ARM 编译器和 ARM 自己的 SDT，我将拥有以下 cmets：
ARM SDT 生成更紧密、更快 代码，但 非常 昂贵（>Eur5k 每个座位！）。在我以前的工作中，我们 用了这个编译器，没问题。
GCC ARM 工具运行良好 虽然这是我自己使用的 项目 (GBA/DS)。
使用“拇指”模式，因为这样可以减少 代码大小显着。在 ARM 的 16 位总线变体（例如 GBA）上也有速度优势。
64k 对于 C++ 来说非常小 发展。我会使用 C 和汇编程序 在那种环境中。
在如此小的平台上，您必须小心使用堆栈。避免递归、大型自动（本地）数据结构等。堆使用也将是一个问题（new、malloc 等）。 C 将让您更好地控制这些问题。
【讨论】：
如果您使用的是针对嵌入式开发或特定嵌入式系统的开发环境，它应该已经限制了您的一些选项。根据您的目标的资源能力，它将关闭一些上述项目（RTTI、异常等）。这是更容易走的路，而不是记住什么会增加大小或内存需求（尽管无论如何你应该在心理上知道这一点）。
【讨论】：
对于嵌入式系统，您主要希望避免具有明确异常运行时成本的事情。一些示例：异常和RTTI（包括dynamic_cast 和typeid）。
【讨论】：
确保您了解编译器支持您的嵌入式平台的哪些功能，并确保您了解您的平台的特性。例如，TI 的 CodeComposer 编译器不执行自动模板实例化。因此，如果要使用 STL 的排序，则需要手动实例化五个不同的东西。它也不支持流。
另一个例子是您可能正在使用一个 DSP 芯片，它没有硬件支持浮点运算。这意味着每次使用浮点数或双精度数时，都需要支付函数调用的费用。
总而言之，了解有关您的嵌入式平台和编译器的所有信息，然后您就会知道要避免哪些功能。
【讨论】：
ATMega GCC 3.something 让我感到惊讶的一个特殊问题是：当我向我的一个类添加一个虚拟 ember 函数时，我必须添加一个虚拟析构函数。此时，链接器要求操作符 delete(void *)。我不知道为什么会发生这种情况，为该运算符添加一个空定义解决了这个问题。
【讨论】：
请注意，异常的成本取决于您的代码。在我分析的一个应用程序（ARM968 上的一个相对较小的应用程序）中，异常支持增加了 2% 的执行时间，并且代码大小增加了 9.5 KB。在这个应用程序中，只有在发生严重错误的情况下才会引发异常 - 即从未在实践中 - 这将执行时间开销保持在非常低的水平。
【讨论】：