[multi_index] use cases for iterator_to()

Hello, More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone: iterator iterator_to(const value_type& x); I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing. Do you see usefulness in having iterator_to()? Can you describe a potential usage scenario? At first blush, seems like this is at least as useful as the homonym functionality in Boost.Intrusive, but if you think about the obvious scenarios applying to B.I, it turns out they do not immediately translate to B.MI. Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

"JOAQUIN LOPEZ MU?Z" wrote:
Hello,
More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone:
iterator iterator_to(const value_type& x);
I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing.
void X::f() { iterator i = iterator_to( *this ); } ?

Hi Peter, ----- Mensaje original ----- De: Peter Dimov <pdimov@mmltd.net> Fecha: Jueves, Mayo 17, 2007 9:12 pm Asunto: Re: [boost] [multi_index] use cases for iterator_to() Para: boost@lists.boost.org
"JOAQUIN LOPEZ MU?Z" wrote:
Hello,
More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone:
iterator iterator_to(const value_type& x);
I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing.
void X::f() { iterator i = iterator_to( *this ); }
?
Yep, but what would you want this iterator for? In the case of intrusive containers, the usual answer is "to extrat the object from the container". In the case of B.MI, which is not intrusive, erasure involves destruction, so things are not so clear. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

"JOAQUIN LOPEZ MU?Z" wrote:
Hi Peter,
void X::f() { iterator i = iterator_to( *this ); }
?
Yep, but what would you want this iterator for? In the case of intrusive containers, the usual answer is "to extrat the object from the container". In the case of B.MI, which is not intrusive, erasure involves destruction, so things are not so clear.
I think that I needed it once to make the object erase itself from its container. You can traverse the container until you find the object, so a helper function is not strictly required, O(1) vs O(N) notwithstanding. I can't recall other use cases for it.

A possible use case is finding the next or previous element in an index, particularly for a sequence index. -- Jeremy Maitin-Shepard

On Thu, 17 May 2007 16:04:57 -0300, JOAQUIN LOPEZ MU?Z <joaquin@tid.es> wrote:
More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone:
iterator iterator_to(const value_type& x);
It was me, I think.
I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing.
Do you see usefulness in having iterator_to()? Can you describe a potential usage scenario? At first blush, seems like this is at least as useful as the homonym functionality in Boost.Intrusive, but if you think about the obvious scenarios applying to B.I, it turns out they do not immediately translate to B.MI.
Yes. My use case was http://thread.gmane.org/gmane.comp.lib.boost.devel/136418/focus=136955 However, now that I look at it, it seems iterator_to is not a solution to that problem. I still think the feature is usefull. For example, you may be forced to pass a raw pointer to a C interface. With iterator_to you can get the position of the element in a collection without overhead. Bruno

Bruno Martínez Aguerre ha escrito:
On Thu, 17 May 2007 16:04:57 -0300, JOAQUIN LOPEZ MU?Z <joaquin@tid.es> wrote:
More than a year ago a request was made for Boost.MultiIndx to provide the ability to get an iterator to an element x from x alone:
iterator iterator_to(const value_type& x);
It was me, I think.
Hello Bruno! Yep, it was your request :)
I can provide this functionality in constant time, and the internal implementation is trivial, but I got thinking about the potential use cases for such capability and cannot come up with something convincing.
Do you see usefulness in having iterator_to()? Can you describe a potential usage scenario? At first blush, seems like this is at least as useful as the homonym functionality in Boost.Intrusive, but if you think about the obvious scenarios applying to B.I, it turns out they do not immediately translate to B.MI.
Yes. My use case was http://thread.gmane.org/gmane.comp.lib.boost.devel/136418/focus=136955
However, now that I look at it, it seems iterator_to is not a solution to that problem.
This is exactly what happened to me when I revisited the request to decide on implementing it.
I still think the feature is usefull. For example, you may be forced to pass a raw pointer to a C interface. With iterator_to you can get the position of the element in a collection without overhead.
I guess I'l finally include it, but it'd be so much nicer if we could find a conclusive use case. I've also thought about legacy interfaces requiring raw pointers, if only we could come up with a simple specific scenario on that line. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (5)
-
"JOAQUIN LOPEZ MU?Z"
-
Bruno Martínez Aguerre
-
Jeremy Maitin-Shepard
-
Joaquín Mª López Muñoz
-
Peter Dimov