C++ Logo

std-proposals

Advanced search

Re: Container.iterator_to for getting an iterator form the reference to value

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Thu, 13 Aug 2020 10:58:18 -0400
On Thu, Aug 13, 2020 at 9:57 AM Antony Polukhin via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> There are useful functions container.iterator_to in Boost.Intrusive
> containers that could be adopted by the Standard Library.
>
> Assuming that the `value` is in the `container`, the call
> `container.iterator_to(value)` returns an iterator to that `value` in
> the container.
>

This is implementable for `std::vector`.
This is implementable for `std::list` and `std::forward_list`, if you are
okay with the library relying on reinterpret_cast.
This is implementable for `std::set` and `std::map`, if you are okay with
the library relying on reinterpret_cast.
This is implementable for `std::unordered_set` and `std::unordered_map`, if
you are okay with the library relying on reinterpret_cast.
This is not implementable for `std::deque` (at least not in O(1)).

To implement `iterator_to` for anything except `vector`, you have to rely
on a cast like this:

struct Node {
    T t;
    Node *next;
};
Node *node_from_t(T *t) {
    return reinterpret_cast<Node *>(t);
}
int main() {
    Node n;
    assert(node_from_t(&n.t) == &n);
}

I'm not sure if this is well-defined. As long as `t` is the first member of
`Node`, I think it might actually be well-defined; but I wouldn't bet money
on it.
Problem is, library implementors tend to be *extremely* loath to rely on
anything smelling of UB in their implementations.

my $.02,
–Arthur

Received on 2020-08-13 10:01:53