2

我正在为嵌入式系统开发一个大项目。该项目是一个库和一些必须集成到客户代码/解决方案中的二进制文件。因此，它必须尽可能独立于操作系统/平台。到目前为止，我们一直在研究嵌入式 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)

这对我来说似乎不太便携（但我可能错了）。

你们怎么看？

非常感谢您的帮助。

4

3 回答 3

1

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

如果它不适用于您的编译器，您可以手动替换代码的冲突部分。Boost 代码更复杂，因为它包含各种编译器错误或缺少功能的解决方法。这就是为什么要添加Boost.Preprocessor或Boost.Typetraits的原因之一。

于 2012-06-26T15:32:35.870 回答
1

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

此外，GCC 的“裸机”端口支持最常见的（不是那么常见和过时的）32 位平台。然而，尽管 GCC 在没有操作系统的情况下是可移植的，但 GNU libc 以 POSIX 兼容的操作系统为目标，因此裸机和非 POSIX 依赖端口通常使用替代库，例如 uClib 或 Newlib。在这些之上 GNU stdlibc++ 将愉快地运行，还有许多 Boost 库。Boost 的某些部分（例如线程）将需要移植到不受支持的目标，纯粹的数据结构相关功能（例如智能指针）将没有目标环境依赖性。

于 2012-06-28T05:02:26.670 回答
1

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

如果您现在没有无法使用 TR1 的客户，请继续使用它。你可以在未来的客户到来时与他们打交道——YAGNI 在这里应用，智能指针非常重要。与移动语义等 C++11 特性一样。

然而，如果你绝望了，你可以自己动手shared_ptr——这个概念并不是特别复杂。

于 2012-06-28T05:32:11.420 回答