相关疑难解决方法(0)

好吧,这真的很难承认,但我现在确实有很强的诱惑力来继承std::vector.

我需要大约10个定制的矢量算法,我希望它们直接成为矢量的成员.但我自然也希望拥有剩下std::vector的界面.好吧,作为一个守法的公民,我的第一个想法是std::vector在MyVector课堂上有一个成员.但是我必须手动重新编写所有std :: vector的接口.打字太多了.接下来,我考虑了私有继承,所以我不会using std::vector::member在公共部分写一些方法而不是重新提取方法.实际上这也很乏味.

在这里,我确实认为我可以简单地从公开继承std::vector,但在文档中提供警告,不应该多态地使用此类.我认为大多数开发人员都有足够的能力去理解这不应该以多态方式使用.

我的决定绝对没有道理吗？如果是这样,为什么？你能提供一个替代方案,其他成员实际上是成员,但不会涉及重新输入所有vector的界面吗？我对此表示怀疑,但如果可以,我会很高兴.

此外,除了一些白痴可以写类似的事实

std::vector<int>* p  = new MyVector

使用MyVector 有任何其他现实危险吗？通过说现实,我放弃像想象一个带有指向矢量的指针的函数...

好吧,我已经陈述了我的情况.我犯罪了.现在由你来原谅我了不起:)

声称使用标准C++容器作为基类是错误的说法让我感到惊讶.

如果没有滥用语言来宣布......

// Example A
typedef std::vector<double> Rates;
typedef std::vector<double> Charges;

......那么确切地说,宣告的危险是什么......

// Example B
class Rates : public std::vector<double> { 
    // ...
} ;
class Charges: public std::vector<double> { 
    // ...
} ;

B的积极优势包括:

• 启用函数重载,因为f(Rates&)和f(Charges&)是不同的签名
• 允许其他模板专用,因为X <Rates>和X <Charges>是不同的类型
• 前瞻性声明是微不足道的
• 调试器可能会告诉您对象是费率还是费用
• 如果随着时间的推移,费率和费用会产生个性 - 一个单一的费率,费用的输出格式 - 这个功能有明显的实施范围.

A的积极优势包括:

• 不必提供构造函数等的简单实现
• 十五年前的预标准编译器是唯一能够编译遗产的编译器
• 由于专业化是不可能的,模板X <费率>和模板X <费用>将使用相同的代码,因此没有毫无意义的膨胀.

这两种方法都优于使用原始容器,因为如果实现从vector <double>更改为vector <float>,那么只有一个地方可以用B更改,也许只有一个地方可以用A更改(可能更多,因为有人可能在多个地方放置了相同的typedef语句.

我的目标是这是一个具体的,可回答的问题,而不是对更好或更差实践的讨论.显示由于从标准容器派生而可能发生的最糟糕的事情,这可以通过使用typedef来防止.

编辑:

毫无疑问,向类Rate或类Charges添加析构函数会有风险,因为std :: vector不会将其析构函数声明为虚拟.示例中没有析构函数,也不需要析构函数.销毁Rates或Charges对象将调用基类析构函数.这里也不需要多态性.挑战在于使用派生而不是使用typedef来表明发生了一些不好的事情.

编辑:

考虑这个用例:

#include <vector>
#include <iostream>

void kill_it(std::vector<double> *victim) { 
    // user code, knows nothing of Rates or …