我想使用 -std=c++0x 在 GCC 中启用对 C++0x 的支持。我绝对不一定需要 GCC 中的任何当前支持的 C++11 功能 4.5（很快就会有 4.6），但我想开始习惯它们。例如，在我使用迭代器的一些地方，auto 类型会很有用。
但同样，我不需要需要任何当前支持的功能。这里的目标是鼓励我将新标准的功能纳入我的编程“词汇”中。
根据您对 C++11 支持的了解，在 GCC 中启用它是一个好主意，然后通过例如从使用 boost::shared_ptr 切换到 来接受它std::shared_ptr 完全不同，因为两者不混合？
PS：我知道这个好问题它比较了不同的shared_ptr 的风格，但我要求在标准最终确定之前就使用哪种方式提出更高级别的建议。另一种说法是，当像 GCC 这样的编译器说它支持“实验性功能”时，这是否意味着我可能在编译过程中遇到奇怪的错误，这些错误将是主要的时间消耗和 StackOverflow 上神秘问题的来源？
编辑：我决定从 std::shared_ptr 切换回来，因为我只是不相信它在 GCC 4.5 中的支持 此问题中的示例所示。
I would like to enable support for C++0x in GCC with -std=c++0x. I don't absolutely necessarily need any of the currently supported C++11 features in GCC 4.5 (and soon 4.6), but I would like to start getting used to them. For example, in a few places where I use iterators, an auto type would be useful.
But again, I don't need any of the currently supported features. The goal here is to encourage me to incorporate the features of the new standard into my programming "vocabulary".
From what you know of the C++11 support, is it a good idea to enable it in GCC, and then embrace it by, for example, switching from using boost::shared_ptr to std::shared_ptr exclusively as the two don't mix?
PS: I'm aware of this good question which compares the different flavors of shared_ptr but I'm asking a higher level advice on which to use before the standard is finalized. Another way of putting that is, when a compiler like GCC says it supports an "experimental feature", does that mean I am likely to encounter weird errors during compilation that will be major time sinks and a source of cryptic questions on StackOverflow?
Edit: I decided to switch back from std::shared_ptr because I just don't trust its support in GCC 4.5 as shown by example in this question.
发布评论
评论（8）
切换到
std::shared_ptr有几个原因：您将获得一个几乎可以保证启用移动语义的实现，这可能会节省一些引用计数修改。 （理论上——我自己没有测试过）至少截至 2014 年 7 月 22 日，boost::shared_ptr理解移动语义。std::shared_ptr在数组类型上正确使用delete []，而boost::shared_ptr在这种情况下会导致未定义的行为（您必须使用shared_array或自定义删除器）unique_ptr，而不是shared_ptr。）还有一个不这样做的明显原因：
最后，你实际上不必选择。 （如果您的目标是特定的编译器系列（例如 MSVC 和 GCC），您可以轻松地扩展它以使用
std::tr1::shared_ptr（如果可用）。不幸的是，似乎没有检测 TR1 支持的标准方法）There are a couple of reasons to switch over to
std::shared_ptr:std::shared_ptrand show the pointed to object directly, where it wouldn't for say, boost's implementation. At least in Visual Studio,std::shared_ptrlooks like a plain pointer in the debugger, whileboost::shared_ptrexposes a bunch of boost's innards.You get an implementation which is almost guaranteed to be move-semantics enabled, which might save a few refcount modifications. (Theoretically -- I've not tested this myself)As of 2014-07-22 at least,boost::shared_ptrunderstands move semantics.std::shared_ptrcorrectly usesdelete []on array types, whileboost::shared_ptrcauses undefined behavior in such cases (you must useshared_arrayor a custom deleter)unique_ptronly, notshared_ptr.)And one major glaring reason not to:
Finally, you don't really have to choose. (And if you're targeting a specific compiler series (e.g. MSVC and GCC), you could easily extend this to use
std::tr1::shared_ptrwhen available. Unfortunately there doesn't seem to be a standard way to detect TR1 support)我想这取决于你使用boost的程度。我个人很少使用它（实际上是随机数库，在一个项目中）。我最近开始在我的其他项目中使用
-std=c++0x，并且在其中使用新的 std:: 库功能，例如共享指针。我希望我的项目具有最少的依赖性，因此我宁愿依赖编译器的标准库实现，而不是 boost。但我认为这个问题没有一个一刀切的答案。
I suppose it depends how much you use boost. I personally only use it very sparingly (in fact the random number library, in a single project). I've recently started using
-std=c++0xfor my other projects, and I use the new std:: library features like shared_ptr in them. I like my projects to have the minimum of dependencies, so I'd rather be dependent on the compiler's standard library implementation than on boost.But I don't think there is a one-size-fits-all answer to this question.
您应该尽可能使用
std::shared_ptr（如果可用），而不是 boost。这基本上是因为所有使用shared_ptr的新接口都将使用标准共享指针。You should always use
std::shared_ptrwherever possible, if it's available, instead of boost. This is basically because all new interfaces which useshared_ptrwill use the Standard shared ptr.在编译器允许的情况下开始养成使用 std::shared_ptr 的习惯可能不是一个坏主意。由于接口与 boost 的shared_ptr 相同，因此如果需要，您可以随时切换回来。
It's probably not a bad idea to start getting into the habit of using std::shared_ptr when allowed by the compiler. Since the interface is the same as boost's shared_ptr you can always switch back if you needed to.
如果您只是在一个平台上进行构建，那就可以了（进行切换）
（注意：您确实有单元测试来验证向后兼容性，不是吗？）
如果您在多个平台上进行编译，情况会变得有点尴尬，因为您需要验证 g++ 4.5 上的功能是否在您的所有平台上可用。使用（即为 MAC/Linux 构建默认的 Mac g++ 编译器仍然比 Linux 上的默认编译器落后几个版本）。
If you are just building on the one platform that is fine (make the switch)
(Note: You do have unit tests to validate backward compatibility don't you?)
If you compile on multiple platforms is where it becomes a little more awkward as you need to validate that the features on g++ 4.5 are available on all the platforms you use (ie building for MAC/Linux the default Mac g++ compiler is still a couple of version's behind the default compilers on Linux).
切换到 std::shared_ptr 的另一个原因：
它支持
std::unique_ptr，即有构造函数。boost::shared_ptr没有。Another reason to switch over to
std::shared_ptr:it supports
std::unique_ptr, i.e. has constructor.boost::shared_ptrdoesn't.std::shared_ptr 至少保留了两个利基优势：
boost::shared_ptr目前比boost.org/doc/libs/1_53_0/libs/smart_ptr/make_shared_array.html" rel="nofollow">boost::make_shared_noinit。它与数组结合使用特别有用，可以避免零初始化的成本和单独分配的开销。 （FWIW，这也是建议添加 符合标准。）boost::shared_ptr对类型擦除自定义删除器的支持，但是 尚未对std::shared_ptr执行相同操作。Aside from implementation consistency,
boost::shared_ptrcurrently retains at least two niche advantages overstd::shared_ptr:boost::make_shared_noinit. It's particularly useful in conjunction with arrays, avoiding both the cost of zero-initialization and the overhead of separate allocation. (FWIW, it's also a proposed addition to the standard.)boost::shared_ptr's support for type-erased custom deleters, but doesn't yet do the same forstd::shared_ptr.我发现 std::shared_ptr 比 boost::shared_ptr 更快。我做了一个测试，您可以查看代码并查看比较 boost、Qt 和 std 共享指针的饼图结果。
https://www.osletek.com...
I found std::shared_ptr to be faster than boost::shared_ptr. I did a test, you can review the code and see the pie chart results comparing boost, Qt, and std shared pointers.
https://www.osletek.com...