我可以/应该从STL迭代器继承吗? [英] Can/Should I inherit from an STL iterator?

问题描述

我可以/应该从STL迭代器继承来实现自己的迭代器类吗?如果没有，为什么不呢?

Can/Should i inherit from STL iterator to implement my own iterator class? If no, why not?

推荐答案

简短答案

许多人认为与常规类型别名相比，类std::iterator没有提供太多帮助，甚至通过不明确提供名称并依赖模板参数的顺序来混淆它们.它在C ++ 17中已弃用，并可能在几年后消失.

Short answer

Many consider that the class std::iterator does not offer much compared to regular type aliases, and even obfuscates them a bit by not explicitly providing the names and relying on the order of the template parameters instead. It is deprecated in C++17 and is likely to be gone in a few years.

这意味着您不再应该使用std::iterator.如果您对全文感兴趣，可以阅读下面的全文(因为它是在弃用提案之前开始的，所以有一些多余之处).

This means that you shouldn't use std::iterator anymore. You can read the whole post below if you're interested in the full story (there's a bit of redundancy since it has been started before the deprecation proposal).

如果您对历史记录不感兴趣，则可以忽略下面的所有内容.以下片段甚至多次自相矛盾.

从今天开始(C ++ 11/C ++ 14)，该标准似乎暗示从std::iterator继承以实现自定义迭代器不再是一个好主意.这是来自 N3931 <的简要说明/a>:

As of today (C++11/C++14), the standard seems to imply that it isn't a good idea anymore to inherit from std::iterator to implement custom iterators. Here is a brief explanation, from N3931:

尽管该标准几乎犯了十次错误，但我还是建议您不要将directory_iterator和recursive_directory_iterator描绘为源自std::iterator，因为这是对实现的约束条件.相反，应该将它们描述为具有适当的typedef，并由实现者决定如何提供它们. (使用is_base_of的用户可以观察到差异，而不是他们应该问这个问题.)

Although the Standard has made this mistake almost a dozen times, I recommend not depicting directory_iterator and recursive_directory_iterator as deriving from std::iterator, since that's a binding requirement on implementations. Instead they should be depicted as having the appropriate typedefs, and leave it up to implementers to decide how to provide them. (The difference is observable to users with is_base_of, not that they should be asking that question.)

[2014-02-08 Daniel评论并提供措词]

此问题基本上类似于regex相关的迭代器)都不是从std::iterator派生的.

This issue is basically similar to the kind of solution that had been used to remove the requirement to derive from unary_function and friends as described by N3198 and I'm strongly in favour to follow that spirit here as well. I'd like to add that basically all "newer" iterator types (such as the regex related iterator) don't derive from std::iterator either.

该文件引用了 N3198 ，该文件本身声明它遵循了

The paper cites N3198 which itself states that it follows the deprecation discussed in N3145. The reasons for deprecating the classes that only exist to provide typedefs are given as such:

我们在概念方面的经验使我们相信，如果类型和功能的可用性足够，则几乎不必依赖于特定的基类派生的类关系.新的语言工具甚至在没有语言支持的概念的情况下也使我们能够推断出类名中类型名的存在，这将在它们之间引入较弱的耦合.用关联的类型替换继承的另一个优点是，这样可以减少出现歧义的情况的数量:如果类型同时从unary_function和binary_function继承，这很容易发生(这很有意义，如果函子既是一元函数又是二进制函数对象.

Our experience with concepts gives us confidence that it is rarely necessary to depend on specific base class-derived class relations, if availability of types and functions is sufficient. The new language tools allow us even in the absence of language-supported concepts to deduce the existence of typenames in class types, which would introduce a much weaker coupling among them. Another advantage of replacing inheritance by associated types is the fact, that this will reduce the number of cases, where ambiguities arise: This can easily happen, if a type would inherit both from unary_function and binary_function (This makes sense, if a functor is both an unary and a binary function object).

tl; dr :仅提供typedef的类现在被认为是无用的.而且，它们在不需要时会增加耦合，更加冗长，并且在某些极端情况下可能会产生有害的副作用(请参阅前面的引用).

tl;dr: classes which only provide typedefs are now deemed useless. Moreover, they increase coupling when it is not needed, are more verbose, and can have unwanted side effects in some corner cases (see the previous quotation).

更新:

Update: issue 2438 from N4245 seems to actually contradict what I asserted earlier:

为了方便LWG，将9个STL迭代器描述为从std::iterator派生以获得其iterator_category/etc. typedefs.不幸的是(这是无意的)，这也要求继承是可观察的(不仅通过is_base_of，而且还有重载解析).这是不幸的，因为它使用户感到困惑，这些用户可能会误以为他们自己的迭代器必须从std::iterator派生，或者认为重载函数来获取std::iterator是有意义的.这也是无意的，因为不需要STL的最重要的迭代器(容器迭代器)从std::iterator派生. (甚至允许某些指针成为原始指针.)最后，这不必要地限制了实现者，他们可能不想从std::iterator派生. (例如，为简化调试器视图.)

For LWG convenience, nine STL iterators are depicted as deriving from std::iterator to get their iterator_category/etc. typedefs. Unfortunately (and unintentionally), this also mandates the inheritance, which is observable (not just through is_base_of, but also overload resolution). This is unfortunate because it confuses users, who can be misled into thinking that their own iterators must derive from std::iterator, or that overloading functions to take std::iterator is somehow meaningful. This is also unintentional because the STL's most important iterators, the container iterators, aren't required to derive from std::iterator. (Some are even allowed to be raw pointers.) Finally, this unnecessarily constrains implementers, who may not want to derive from std::iterator. (For example, to simplify debugger views.)

总而言之，我错了，@ aschepler是正确的:可以使用 ，但是肯定不是必需的-也不要泄气.整个让我们删除std::iterator"一词对于标准来说是不限制标准库实现者的.

To sum up, I was wrong, @aschepler was right: it can be used, but it is certainely not required - it isn't discouraged either. The whole "let's remove std::iterator" thing exists for the standard not to constrain the standard library implementers.

第三轮:

Round 3: P0174R0 proposes to deprecate std::iterator for a possible removal in the future. The proposal is already pretty good at explaining why it should be deprecated, so here we go:

无效参数的长序列对读者而言不像在类定义本身中简单地提供期望的typedef那样清晰，这是当前工作草案采用的方法，遵循C ++ 14中设置的模式不推荐从funary函数库中从unary_function和binary_function派生.

The long sequence of void arguments is much less clear to the reader than simply providing the expected typedefs in the class definition itself, which is the approach taken by the current working draft, following the pattern set in C++14 where we deprecated the derivation throughout the library of functors from unary_function and binary_function.

除了降低清晰度之外，迭代器模板还为粗心的人设置了一个陷阱，因为在典型用法中，它将是一个依赖的基类，这意味着在名称查找过程中，它将不会从该类或其内部进行查找.成员函数.这导致惊讶的用户试图理解为什么以下简单用法不起作用:

In addition to the reduced clarity, the iterator template also lays a trap for the unwary, as in typical usage it will be a dependent base class, which means it will not be looking into during name lookup from within the class or its member functions. This leads to surprised users trying to understand why the following simple usage does not work:

#include <iterator>

template <typename T>
struct MyIterator : std::iterator<std::random_access_iterator_tag, T> {
   value_type data;  // Error: value_type is not found by name lookup 

   // ... implementations details elided ...
};

仅出于清晰性的原因就足以说服LWG来更新标准库规范，以不再要求标准迭代器适配器来自于std :: iterator，因此在标准本身内不再需要使用此模板.因此，它似乎很适合弃用.

The reason of clarity alone was sufficient to persuade the LWG to update the standard library specification to no longer mandate the standard iterator adapators as deriving from std::iterator, so there is no further use of this template within the standard itself. Therefore, it looks like a strong candidate for deprecation.

这变得有些累人，似乎并不是每个人都同意，所以我让你得出自己的结论.如果委员会最终决定不推荐使用std::iterator，那么它将很清楚地表明您不应再使用它.请注意，后续论文突出显示了删除std::iterator的强大支持:

This is becoming a bit tiring and not everyone seems to agree, so I will let you draw your own conclusions. If the committee eventually decides that std::iterator should be deprecated, then it will make it pretty clear that you shouldn't use it anymore. Note that the follow-up paper highlights a great support for the removal of std::iterator:

杰克逊维尔，2016年更新:

投票:弃用iterator for C ++ 17?
SF F N A SA
6 10 10 1 0 0

Poll: Deprecate iterator for C++17??
SF  F   N   A   SA
6    10  1    0   0

在以上民意调查结果中， SF ， F ， N ， A 和 SA 代表坚决反对，赞成，中立，反对和坚决反对.

In the above poll results, SF, F, N, A and SA stand for Strongly For, For, Neutral, Against and Strongly Against.

Oulu，2016年更新:

投票:仍要弃用std::iterator?
SF F N A SA
3 6 3 3 2 0

Poll: Still want to deprecate std::iterator?
SF F N A SA
3   6  3  2  0

P0619R1 建议删除std::iterator，可能最早在C ++ 20时删除，并且还建议增强std::iterator_traits，以便它可以自动推断difference_type，pointer和reference类型，就像std::iterator一样没有明确提供.

P0619R1 proposes to remove std::iterator, possibly as soon as C++20, and also proposes to enhance std::iterator_traits so that it can automatically deduce the types difference_type, pointer and reference the way std::iterator does when they're not explicitly provided.

这篇关于我可以/应该从STL迭代器继承吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！