C++:STL和Boost的替代方案?

Ash*_*ppa 19 c++ boost stl

C++是一种多范式语言,STLBoost是针对语言的功能范例而构建的.STL由容器(用于保存数据),迭代器(用于访问数据)和算法(用于操作数据的函数)组成.通过使用迭代器将算法函数应用于容器.作为副作用,这些方法不是容器类的一部分,而是完全独立的.(这避免了库编写者的冗余,但对于库用户来说却很痛苦.)

是否有STL/Boost的C++替代品,以更传统的面向对象的方式提供这样的容器?我正在寻找字符串,向量,链表,地图,树,哈希表等.容器应该易于继承和扩展.相比之下,从STL/Boost扩展类是一个非常糟糕的想法,这是他们的设计师的设计.

PS:请不要使用下面的回复空间来证明STL/Boost的优势.我很清楚他们!:-)

Jer*_*fin 31

许多(大多数!)旧的C++库使用的容器与Java和C#中使用的容器更为相似.

这些库的一些例子包括COOL,ET ++,NIH类库Rogue Wave Tools.h ++.

两点:

  1. 至多,这些是灵感来源.我很确定它已经至少10年(通常更像是20年),因为它们中的任何一个都已更新.几乎没有任何机会甚至可以使用任何合理的当前编译器进行编译.
  2. 我想记录在案,指出我只是在回答一个非常具体的问题时提供这些链接.我绝对不建议您使用上述任何代码,也不建议您甚至将它们用作灵感.

为了确保我在这里清楚,至少IMO:

  • 你问题中的指控是完全错误的.
  • 你要做的是完全疯了!
  • 你在浪费你的时间.
  • 以这种方式编写代码是一个非常非常糟糕的主意.拒绝吧!
  • 如果你坚持这样做,你将成为一个贱民.
    1. 即使是那些不太了解原因的非程序员,也会开始强烈地恨你.
    2. 你的狗会用你的鞋子和床作为他的厕所.

你是独自一人.你被警告了!

对于幽默受损的隐藏式字幕:当然其中一些是幽默的 - 虽然这一个非常非常糟糕的想法


In *_*ico 25

这避免了库编写者的冗余,但对于库用户来说却很痛苦.

我根本不同意这个前提.即使我这样做,也是一个巨大的过度概括,并不适用于每个图书馆用户.但无论如何这是一个主观陈述,所以我会忽略它.


是否有STL/Boost的C++替代品,以更传统的面向对象的方式提供这样的容器?

...

容器应该有允许人们直接操作它们的方法.(例如,调用vector.sort()而不是sort(vector.begin(),vector.end()).

当然.只需创建自己的容器,将标准容器作为数据成员,并根据需要通过成员函数委托对它们和算法的调用.实施起来相当简单:

template<typename T>
class MyVector
{
public:
    void sort()
    {
        std::sort(vec.begin(), vec.end());
    }

    // ...
private:
    std::vector<T> vec;
};
Run Code Online (Sandbox Code Playgroud)

C++中没有任何东西可以阻止你做这样的事情,具有讽刺意味的是,由于你似乎不同意C++的多范式特性.

如果您不想写出包装函数,则可以使用private继承和using声明.


STL/Boost使得从容器中获取并扩展它们变得很痛苦.

那是因为你不应该从他们那里得到.正确的方法是使用组合,就像我上面提到的代码片段.

  • STL的整个目标是容器的易扩展性.只需添加另一个非成员非朋友功能即可.如果您想在提议的实现中扩展容器,那将是一件痛苦的事. (11认同)
  • In silico:通过组合,您最终会再次为所有需要的方法重写包装器.我这样做了,很痛苦. (2认同)

Jan*_*dec 7

STL和Boost是面向对象的,你可以得到它.

  1. 出于所有理论目的,成员函数和第一个参数上重载的自由函数是相同的.它们在实践中表现非常相似,包括继承,所以在C++中你应该考虑将(可能是const)引用作为第一个参数的自由函数作为它们的第一个参数的方法.

    自由函数的优点是可以为现有类定义它们,允许您向现有类添加接口.这就是为什么STL,特别是强化使用它们的原因.成员函数的主要优点是它们可以是虚拟的(但虚拟方法应该是私有的!)

  2. 您不希望通过派生来扩展集合.通常,您不希望通过派生来扩展任何内容,除非它是专门为其设计的抽象基类.关于组合优于继承的优点,请参阅此问题.


wil*_*ell 6

你走错了路.如果你想用Java编程,那么用Java编程.如果你用C++编程,那么就像C++程序员那样编程.永远与当前游泳,永远不要反对它.

  • @Ashwin:"但是,当你想用团队建立一个大的东西时,你需要强制只使用C++的一个子集." - 同样,我不同意这个前提.为什么需要强制只使用C++的子集?特别是如果该子集恰好是解决问题的最简洁方法? (4认同)
  • @Ashwin:你为什么一直坚持认为Qt的方法与STL不同.这不是真的! (4认同)
  • 如果这正是您不感兴趣的答案,我很抱歉.但C++不是"面向对象的语言".尝试使用C++成为"面向对象的纯粹主义者"是完全错误的. (2认同)
  • @Ashwin:我从来没说过你.但请考虑除了您同意的人之外,其他可能不同意您提供的博客文章的人做的事情.我们不是白痴; 如果"STL-way"如此糟糕,我们将不会使用它! (2认同)

One*_*One 5

看看Qt的做法,我一直是它的粉丝。

更新了链接。

  • 什么?!Qt 容器与 STL 容器几乎相同。没有虚函数,没有包含的排序语句等。它们有什么不同? (16认同)