嵌入式C++项目-需要智能指针支持。可能的可移植性问题？

Question

我正在做一个嵌入式系统的大项目。该项目是一个库和一些二进制文件，必须集成到客户的代码/解决方案中。因此，它必须尽可能地与操作系统/平台无关。到目前为止，我们一直在研究嵌入式linux，没有出现任何问题。然而，在不久的将来，非基于linux的平台也有可能加入这一行列。

为了展示我们正在使用的平台类型，它们必须能够运行要求苛刻的模块，如Java虚拟机。

我不确定会出现哪种类型的平台，以及它们可能提供什么样的编译器。所以我有点担心使用高级的C++期货或库，这可能会带来很多麻烦。我主要是想避免因此而导致的不兼容的可能性。

我们正在重构我们解决方案的几个C++模块。它们真的很棘手，智能指针支持将会有很大帮助。一开始，我想做一个自定义的智能指针包，但这对我来说似乎有一点风险(这里的bug会造成巨大的头痛)。所以我考虑使用boost的智能指针。

如果我使用boost的智能指针，你们觉得我将来会有麻烦吗？

我试着用bcp来解压boost的智能指针包，但是随之而来的还有很多其他的东西。大约4Mb的代码。解压缩后的目录为：

config/compiler
config/stdlib
config/platform
config/abi
config/no_tr1
detail
smart_ptr
mpl (and subdirs)
preprocessor (and subdirs)
exception (and subdirs)
type_traits (and dubdirs)

这对我来说似乎不是很容易移植(但我可能错了)。

你们觉得怎么样？

非常感谢你的帮助。

Answer 1

较新的编译器包括shared_ptr as C++11/TR1。如果你有一个相当现代的编译器--这是你真正想要的，因为C++11- -那么它应该不会有问题。

如果你现在没有不能使用TR1的客户，那就继续努力吧。你可以在未来的客户到来时与他们打交道- YAGNI在这里适用，并且智能指针非常重要。像移动语义这样的C++11特性也是如此。

然而，如果你感到绝望，你可以推出自己的shared_ptr- -这个概念并不是特别复杂。

Answer 2

不要犹豫使用智能指针。您提取的智能指针包应该可以移植到所有像样的编译器。

如果它不能与您的编译器一起工作，您可以手动替换代码的冲突部分。Boost代码更为复杂，因为它包含针对各种编译器错误或缺失功能的变通方法。这就是添加Boost.Preprocessor或Boost.Typetraits的原因之一。

Answer 3

Boost非常便携；库的源代码大小并不代表目标映像的大小；许多库代码将保持未使用状态，并且不会包含在目标映像中。

此外，大多数常见的(不是那么常见和过时的)32位平台都是由一个“裸机”端口支持的，即GCC。然而，虽然GCC可以在没有操作系统的情况下移植，但GNU libc针对的是POSIX兼容的操作系统，因此裸机和非POSIX依赖的端口通常使用替代库，如uClib或Newlib。最重要的是，GNU将会运行得很愉快，也会有很多Boost库。Boost的某些部分，如线程，将需要移植到不支持的目标，纯数据结构相关的功能，如智能指针，将没有目标环境依赖。