容器上的项回调或为什么STL没有指向迭代器转换的指针？ [英] item callback on container or why STL does not have pointer to iterator conversion open?
问题描述
让我们说一下当对象在容器中有子对象时的常见情况
并从包含的项中接收回调。和对象想要移动
容器中的对象信号（回调）。
迭代器需要进行容器修改，项目无法知道它
iterator，至少它不容易这样做，我认为无法完成
类型安全避免虚拟功能和东西。
''这个''来自项目的指针是一个freeby：>。
问题是，std容器想要完全线性扫描从指针找到迭代器
，而从实现端转换指向
std :: list或std :: map iterator是免费的（从指针获取
std :: list :: node然后从节点构造迭代器）
为什么要这样做？这使std容器无法用于描述
子容器回调场景 - 试图在回调中移动
项目的巨大开销。
lets say its common situation when object have subobjects in container
and receives callbacks from contained items. and object want to move
objects in containers on signal(callback).
iterator is needed for container modifications, item cannot know its
iterator, at least its not easy to do so and i think cannot be done
type-safe avoiding virtual functions and stuff.
''this'' pointer from items is a freeby :>.
the problem is, std containers want full linear scan to find iterator
from pointer, while from implemention side converting pointer to
std::list or std::map iterator is free (substracting offset to get
std::list::node from pointer and then construct iterator from node).
why this is done so? this makes std containers unusable in described
child to container callback scenarios - huge overhead trying to move
item in container on callback.
推荐答案
forester写道：
forester wrote:
让我们说一下当对象在容器中有子对象时的常见情况
从包含的项目接收回调。和对象想要移动容器上的对象信号（回调）。
迭代器是容器修改所必需的，项目无法知道它的迭代器，至少它不容易做到所以我认为无法做到
类型安全避免虚拟功能和东西。
''这个'来自项目的指针是一个freeby：>。
问题是，std容器需要完全线性扫描才能从指针中找到迭代器，而从实现端转换指针到st / :: std :: list或std :: map iterator是免费的（减去偏移量来获得
std :: list ::节点从指针，然后从节点构造迭代器）。
如果不使用reinterpret_cast或c-style强制转换，并且
调用实现定义的行为，则无法完成。
为什么这是这样做了吗？这使得std容器在描述的容器回调场景中无法使用 - 在回调时试图在容器中移动
项目的巨大开销。
lets say its common situation when object have subobjects in container
and receives callbacks from contained items. and object want to move
objects in containers on signal(callback).
iterator is needed for container modifications, item cannot know its
iterator, at least its not easy to do so and i think cannot be done
type-safe avoiding virtual functions and stuff.
''this'' pointer from items is a freeby :>.
the problem is, std containers want full linear scan to find iterator
from pointer, while from implemention side converting pointer to
std::list or std::map iterator is free (substracting offset to get
std::list::node from pointer and then construct iterator from node).
this cannot be done without using reinterpret_cast or c-style cast and
invoking implementation-defined behavior.
why this is done so? this makes std containers unusable in described
child to container callback scenarios - huge overhead trying to move
item in container on callback.
有container be std :: set< child *>或者可能是非标准的
hash_set。在这些情况下，从子*中检索迭代器对于大多数需求来说足够快。
have the container be std::set<child*> or perhaps a non-standard
hash_set. in those cases, retrieving an iterator from a child* would be
sufficiently fast for most needs.
不需要reinterpret_cast ，static_cast很好，来自
list / tree的节点可以看这个：
模板< class T>
struct节点：T {
节点< T> * prev_;
node< T> * next_;
};
T * ptr;
node< T> * node_ptr = static_cast< node< T> *>（ptr）;
使用std :: set< T *>或非标准哈希来执行操作，可以通过一个处理器实现完成看起来很疯狂，imho。
reinterpret_cast is not needed, static_cast well be ok, node from
list/tree can look this:
template <class T>
struct node : T {
node<T> *prev_;
node<T> *next_;
};
T *ptr;
node<T> *node_ptr = static_cast<node<T>* >(ptr);
using std::set<T*> or non-standart hash to perform operation that can
be done by one processor instuction looks insane, imho.
forester写道：
forester wrote:
不需要reinterpret_cast，static_cast也没关系，
list / tree中的节点可以看这个：
模板< class T>
struct node：T {
node< T> * prev_;
节点< T> * next_;
};
T * ptr;
节点< T> * node_ptr = static_cast< node< T> *>（ptr）;
使用std :: set< T *>或者非标准哈希来执行可以由一个处理器实现的操作看起来很疯狂，imho。
reinterpret_cast is not needed, static_cast well be ok, node from
list/tree can look this:
template <class T>
struct node : T {
node<T> *prev_;
node<T> *next_;
};
T *ptr;
node<T> *node_ptr = static_cast<node<T>* >(ptr);
using std::set<T*> or non-standart hash to perform operation that can
be done by one processor instuction looks insane, imho.
我将回复此问题，直到我看到了这样的断言，即没有做什么，这是疯狂的。这不是鼓励讨论的好方法。我会只是说b $ b说你的黑客可能会在某些情况下工作，但它不完整，而且它不适用于其他类型的容器。
-
Pete Becker
Dinkumware，Ltd。（ http://www.dinkumware.com ）
这篇关于容器上的项回调或为什么STL没有指向迭代器转换的指针？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
