我正在开发一个嵌入式系统的大项目。 该项目是一个库和一些二进制文件，必须集成到客户的代码/解决方案中。 因此，它必须尽可能独立于OS /平台。 到目前为止，我们一直在研究嵌入式Linux，没有任何问题。然而，基于非Linux的平台有可能在不久的将来加入这种乐趣。
为了说明我们正在使用的平台，他们必须能够运行要求苛刻的模块，例如Java虚拟机。
我不确定哪种平台可能出现以及它们可能提供哪种编译器。 所以我有点担心使用可能会造成很多麻烦的高级C ++期货或库。主要是我想避免因此而导致不兼容的可能性。
我们正在重构我们解决方案的一些C ++模块。他们真的很棘手，聪明的指针支持会有很大帮助。 起初，我想过制作一个自定义智能指针包，但对我来说似乎有点风险（这里的错误会引起巨大的麻烦）。 所以我想过使用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)
这对我来说似乎不太方便（但我可能错了）。
你们怎么看？
非常感谢你的帮助。
答案 0 :(得分：1)
使用智能指针时请不要犹豫。您提取的智能指针包应该可以移植到所有体面的编译器。
如果它不能与您的编译器一起使用，您可以手动替换冲突的代码部分。 Boost代码更复杂，因为它包含各种编译器错误或缺少功能的变通方法。这就是为什么添加Boost.Preprocessor或Boost.Typetraits的原因之一。
答案 1 :(得分：1)
Boost非常便携;库的源代码大小不表示目标图像大小;大部分库代码将保持未使用状态，不会包含在目标图像中。
此外，最常见的（并非常见和过时的）32位平台由GCC的“裸机”端口支持。然而，虽然GCC在没有操作系统的情况下是可移植的，但GNU libc的目标是POSIX兼容的操作系统，因此裸机和非POSIX依赖端口通常使用替代库，如uClib或Newlib。除了这些GNU之外，stdlibc ++还可以运行得很快，还有很多Boost库。诸如线程之类的Boost部分需要移植到不支持的目标，纯粹的数据结构相关功能（如智能指针）将没有目标环境依赖性。
答案 2 :(得分：1)
较新的编译器包括shared_ptr作为C ++ 11 / TR1。如果你有一个相当现代的编译器 - 你真的想拥有它，因为C ++ 11-那么它应该没有问题。
如果你现在没有一个不能使用TR1的顾客，那么请继续使用它。您可以在他们到达时与未来的客户打交道--YAGNI适用于此处，而智能指针非常重要。与C ++ 11的特性一样，如移动语义。
然而，如果你绝望，你可以推出自己的shared_ptr - 这个概念并不是特别复杂。