从STL容器派生 [英] Deriving from a STL container
问题描述
有人能告诉我为什么从STL容器继承
被认为是不好的做法吗？
当你想自定义STL容器时，你呢？意味着我需要
写大量的代码只是为了避免从中衍生出来？
10月30日，12日：下午50点，mosfet< john .... @ anonymous.orgwrote：
有人能告诉我为什么它被认为是继承的不良做法/>
来自STL容器？
当你想自定义STL容器时，你的意思是我需要
写大量的代码只是为了避免从中衍生出来的？
STL容器不是用虚拟析构函数编写的。您可以自己打开内存泄漏。对std容器的任何扩展都可以
不保证与std算法的兼容性，你的客户将需要知道这一点。
您不需要重写吨代码，标准做法是使用合成并使适配器类拥有。 std容器，
以及首先扩展容器所需的额外功能
。
bjeremy写道：
10月30日下午12:50，mosfet< john .... @ anonymous.orgwrote：
< blockquote class =post_quotes>
>有人可以告诉我为什么从STL容器继承
被认为是不好的做法吗？
当你想自定义STL容器时，你的意思是我需要编写大量的代码以避免从中衍生出来吗？
STL容器不是用虚拟析构函数编写的。您可以自己打开内存泄漏。
实际上，未定义的行为，如果你的意思是试图以多态方式调用d-tor
。
对std容器的任何扩展都可能
不能保证与std算法的兼容性，你的客户会想要b / b
需要注意这一点。
我不确定你的意思。
你不需要重写吨代码，标准做法是使用组合并使适配器类具有的标准做法。 std容器，
加上你需要扩展容器所需的额外功能
。
....这也可以通过私人继承实现，上次我看。
无论如何，有一些问题需要考虑，但有一些问题没有硬性规则说不要继承。
V
-
请在通过电子邮件回复时删除资金''A'
我没有回复最热门的回复，请不要问
10月30日下午1点38分，Victor Bazarov < v.Abaza ... @ comAcast.netwrote：
bjeremy写道：
10月30，下午12:50，mosfet< john .... @ anonymous.orgwrote：
有人能告诉我为什么它被认为是不好的做法从STL容器继承
？
当你想自定义STL容器时，你的意思是我需要
只写大量的代码避免从中衍生出来？
STL容器不是用虚拟析构函数编写的。您可以自己打开内存泄漏。
实际上，未定义的行为，如果你的意思是试图以多态方式调用d-tor
。
是的我的意思是多态地调用d-tor
对std容器的任何扩展都可以
不保证与std算法的兼容性，你的客户将需要知道这一点。
我不确定你的意思。
我的意思是如果你提供你的扩展名为替换std
容器，不要做任何会破坏容器的api更改
与任何std algs一起使用。
您不需要重写吨代码，标准做法是使用构图和制作来实现
适配器类有一个 std容器，
加上你需要扩展容器所需的额外功能
。
...这也可以通过私人继承实现，我上次看。
真的..所以你在不需要覆盖虚拟的情况下提升私有继承作为
组合的替代方案/>
函数..其中std容器没有？
>
在任何情况下，都有一些问题需要考虑，但有
没有硬性规则说不要继承。
V
-
请删除大写''A'' s通过电子邮件回复
我没有回复最热门的回复，请不要问
Could someone tell me why it''s considered as bad practice to inherit
from STL container ?
And when you want to customize a STL container, do you mean I need to
write tons of code just to avoid to derive from it ?
On Oct 30, 12:50 pm, mosfet <john....@anonymous.orgwrote:Could someone tell me why it''s considered as bad practice to inherit
from STL container ?
And when you want to customize a STL container, do you mean I need to
write tons of code just to avoid to derive from it ?STL Containers are not written with virtual destructors. You may open
yourself up to memory leaks. Also any extension to a std container may
not guarantee compatability with the std algorithms, you clients would
need to be aware of this.
You shouldn''t need to rewrite "tons of code", a standard practice is
to use composition and make an adapter class "have a" std container,
plus whatever extra functionality you need to extend the container for
in the first place.
bjeremy wrote:On Oct 30, 12:50 pm, mosfet <john....@anonymous.orgwrote:>Could someone tell me why it''s considered as bad practice to inherit
from STL container ?
And when you want to customize a STL container, do you mean I need to
write tons of code just to avoid to derive from it ?
STL Containers are not written with virtual destructors. You may open
yourself up to memory leaks.Actually, undefined behaviour, if you mean trying to invoke the d-tor
polymorphically.
Also any extension to a std container may
not guarantee compatability with the std algorithms, you clients would
need to be aware of this.I am not sure what you mean by this.
You shouldn''t need to rewrite "tons of code", a standard practice is
to use composition and make an adapter class "have a" std container,
plus whatever extra functionality you need to extend the container for
in the first place..... which can also be achieved by private inheritance, last time I looked.
In any case, there are issues that need to be considered, but there is
no hard rule saying "do not inherit".
V
--
Please remove capital ''A''s when replying by e-mail
I do not respond to top-posted replies, please don''t ask
On Oct 30, 1:38 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:bjeremy wrote:On Oct 30, 12:50 pm, mosfet <john....@anonymous.orgwrote:Could someone tell me why it''s considered as bad practice to inherit
from STL container ?
And when you want to customize a STL container, do you mean I need to
write tons of code just to avoid to derive from it ?
STL Containers are not written with virtual destructors. You may open
yourself up to memory leaks.
Actually, undefined behaviour, if you mean trying to invoke the d-tor
polymorphically.
Yes I mean invoking the d-tor polymorphically
Also any extension to a std container may
not guarantee compatability with the std algorithms, you clients would
need to be aware of this.
I am not sure what you mean by this.
I mean if you offer your extension as a replacement for a std
container, don''t make any api changes that would break the containers
use with any of the std algs.
You shouldn''t need to rewrite "tons of code", a standard practice is
to use composition and make an adapter class "have a" std container,
plus whatever extra functionality you need to extend the container for
in the first place.
... which can also be achieved by private inheritance, last time I looked.Really.. so you promote private inheritance as an alternative to
composition in the cases where you do not need to override virtual
functions.. of which std containers have none?>
In any case, there are issues that need to be considered, but there is
no hard rule saying "do not inherit".
V
--
Please remove capital ''A''s when replying by e-mail
I do not respond to top-posted replies, please don''t ask
这篇关于从STL容器派生的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
