Question

结合使用autoconf的最佳做法是什么？使用shared_ptr和其他TR1 / BOOST C ++ 0x模板以便最大化可移植性和可维护性？

使用autoconf我可以确定shared_ptr是否为std::tr1::shared_ptr 以boost::shared_ptr和/或shared_ptr提供。特定同一个功能有两个不同的名称，我有以下几点问题：

在代码中，应该如何引用std::tr1::shared_ptr？
boost::shared_ptr优先于shared_ptr？

首先，代码当前正在使用预处理器条件允许对#if HAVE_STD_TR1_SHARED_PTR using std::tr1::shared_ptr; #elif HAVE_BOOST_SHARED_PTR using boost::shared_ptr; #else #error "No definition for shared_ptr found" #endif，la

std::tr1::

其次，代码使用boost::而不是{{1}}来最小化对外部库的依赖（即使库是广泛使用）。

这两种解决方案是否常见？还有更好的吗？

Answer 1

对示例代码的一个改进，以及对第一个问题的回答，是使用“template typedef”成语：

#if HAVE_STD_TR1_SHARED_PTR
    template <class T>
    struct SharedPtr {
        typedef std::tr1::shared_ptr<T> Type;
    };
#elif HAVE_BOOST_SHARED_PTR
    template <class T>
    struct SharedPtr {
        typedef boost::shared_ptr<T> Type;
    };
#else
#   error "No definition for shared_ptr found"
#endif

// Declare a shared_ptr using our wrapper classes, saving us from having to care
// where shared_ptr comes from:
SharedPtr<int>::Type my_shared_int(new int(42));

这个问题的主要问题是需要使用:: Type表示法。这纯粹是因为C ++目前无法为模板提供typedef。您可以为模板类型实例设置typedef，但在此重要的是保持通用性。

至于你是否应该选择TR1来提升，我会说是的。既然编译器正在提供部分C ++ 0x支持，我会说你也应该测试std :: shared_ptr并且更喜欢其他任何一个。

如果编译器的shared_ptr位于其他位置，则可能需要第四个typedef。我不知道这样的编译器，但是我维护的一些C ++代码与标准C ++库的常见slist扩展相似，对于单链接列表。旧的g ++版本将它放在全局命名空间中，现代g ++将它放在特定于编译器的__gnu_cxx命名空间中，我们甚至发现错误地将它放在std中！

如何使用具有C ++ 0x功能的autoconf

1 个答案: