c++ - 包装容器以保持一致性

Question

我想知道包装 C++ STL 容器以保持一致性并能够在不修改客户端代码的情况下交换实现是否是个好主意。

例如，在一个项目中，我们使用 CamelCase 命名类和成员函数 ( Foo::DoSomething() )，我会包装 std::list进入这样的类:

template<typename T>
class List
{
    public:
        typedef std::list<T>::iterator Iterator;
        typedef std::list<T>::const_iterator ConstIterator;
        // more typedefs for other types.

        List() {}
        List(const List& rhs) : _list(rhs._list) {}
        List& operator=(const List& rhs)
        {
            _list = rhs._list;
        }

        T& Front()
        {
            return _list.front();
        }

        const T& Front() const
        {
            return _list.front();
        }

        void PushFront(const T& x)
        {
            _list.push_front(x);
        }

        void PopFront()
        {
            _list.pop_front();
        }

        // replace all other member function of std::list.

    private:
        std::list<T> _list;
};

然后我就可以这样写了:

typedef uint32_t U32;
List<U32> l;
l.PushBack(5);
l.PushBack(4);
l.PopBack();
l.PushBack(7);

for (List<U32>::Iterator it = l.Begin(); it != l.End(); ++it) {
    std::cout << *it << std::endl;
}
// ...

我相信大多数现代 C++ 编译器都可以轻松地优化掉额外的间接寻址，而且我认为这种方法有一些优点，例如:

我可以轻松地扩展 List 类的功能。例如，我想要一个对列表进行排序然后调用 unique() 的速记函数，我可以通过添加一个成员函数来扩展它:

 template<typename T>
 void List<T>::SortUnique()
 {
     _list.sort();
     _list.unique();
 }

此外，我可以交换底层实现(如果需要)，而无需对他们使用的代码进行任何更改 List<T>只要行为相同。还有其他好处，因为它保持了项目中命名约定的一致性，所以它没有 push_back()用于 STL 和 PushBack()对于项目中的其他类，例如:

std::list<MyObject> objects;
// insert some MyObject's.
while ( !objects.empty() ) {
    objects.front().DoSomething();
    objects.pop_front();
    // Notice the inconsistency of naming conventions above.
}
// ...

我想知道这种方法是否有任何主要(或次要)缺点，或者这是否真的是一种实用方法。

好的，感谢您到目前为止的回答。我想我可能在问题的命名一致性上投入了太多。实际上命名约定在这里不是我关心的，因为也可以提供完全相同的接口(interface):

template<typename T>
void List<T>::pop_back()
{
    _list.pop_back();
}

或者甚至可以使另一种实现的接口(interface)看起来更像大多数 C++ 程序员已经熟悉的 STL 接口(interface)。但无论如何，在我看来，这更像是一种风格，根本不那么重要。

我关心的是能够轻松更改实现细节的一致性。堆栈可以通过多种方式实现:数组和顶部索引，链表甚至两者的混合，它们都具有数据结构的后进先出特性。自平衡二叉搜索树也可以用AVL树或红黑树来实现，它们都有O(logn)。查找、插入和删除的平均时间复杂度。

那么如果我有一个AVL树库和另一个接口(interface)不同的红黑树库，我用一个AVL树来存储一些对象。后来，我想(使用探查器或其他)使用红黑树可以提高性能，我将不得不转到使用 AVL 树的文件的每个部分，并更改类、方法名称和可能的参数命令到它的红黑树同行。甚至在某些情况下，新类可能还没有编写等效的功能。我认为它也可能会引入细微的错误，也可能是因为实现上的差异，或者我犯了一个错误。

所以我开始怀疑维护这样一个包装类以隐藏实现细节并为不同实现提供统一接口(interface)是否值得开销:

template<typename T>
class AVLTree
{
    // ...
    Iterator Find(const T& val)
    {
        // Suppose the find function takes the value to be searched and an iterator
        // where the search begins. It returns end() if val cannot be found.
        return _avltree.find(val, _avltree.begin());
    }
};

template<typename T>
class RBTree
{
    // ...
    Iterator Find(const T& val)
    {
        // Suppose the red-black tree implementation does not support a find function,
        // so you have to iterate through all elements.
        // It would be a poor tree anyway in my opinion, it's just an example.
        auto it = _rbtree.begin(); // The iterator will iterate over the tree
                                   // in an ordered manner.
        while (it != _rbtree.end() && *it < val) {
            ++it;
        }
        if (*++it == val) {
            return it;
        } else {
            return _rbtree.end();
        }
    }
};

现在，我只需要确保 AVLTree::Find()和 RBTree::Find()做完全相同的事情(即获取要搜索的值，将迭代器返回到元素或 End() ，否则)。然后，如果我想从 AVL 树更改为红黑树，我所要做的就是更改声明:

AVLTree<MyObject> objectTree;
AVLTree<MyObject>::Iterator it;

到:

RBTree<MyObject> objectTree;
RBTree<MyObject>::Iterator it;

通过维护两个类，其他一切都将相同。

Answer 1

I'm wondering if this approach has any major (or minor) disadvantages,

两个词:维护噩梦。

然后，当您获得一个新的支持移动的 C++0x 编译器时，您将不得不扩展所有包装类。

请不要误会我的意思——如果您需要额外的功能，包装一个 STL 容器并没有错，但只是为了“一致的成员函数名称”？太多的开销。投入太多时间却没有投资返回率。

我应该补充一点:不一致的命名约定只是您在使用 C++ 时遇到的问题。太多可用(和有用)的库中有太多不同的样式。