Re: [boost] [multi_index] use cases for iterator_to()

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-06-10 17:30:50

Hi Paul, excuse my late anwering,

----- Mensaje original -----
De: Paul Rose <prose_at_[hidden]>
Fecha: Viernes, Junio 8, 2007 11:15 pm
Asunto: Re: [boost] [multi_index] use cases for iterator_to()
Para: boost_at_[hidden]

> >> I guess I'l finally include it, but it'd be so much nicer if we 
> couldfind
> >> 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.
> 
> Hi,
> 
> Occasionally I want this feature, but admittedly for a fairly weak
> reason:
> 
> Checking for NULL:
> 
> 	if(p) ...
> 
> is more convenient than checking for end:
> 
> 	if(i == c.end()) ...
> 
> If most of the time I need only to check for NULL or dereference 
> then a pointer is more convenient.  When I occasionally need
> to erase() then I can use iterator_to...

Well, it is definitely not the intention of this feature to
promote the use of pointers instead of iterators :) the latter
are richer types and can detect problems in your code both
at compile time (vg. adding an offset to a bidirectional
iterator) and at run time (vg. via Boost.MultiIndex safe mode).
iterator_to() would be oriented to very specific uses, for
instance when needed because of requirements from legacy
APIs as Bruno suggests.

In which sense is the use of pointers rather than iterators
"more convenient"?

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo