F
forester
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.
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.