Re: [boost] tie alternative?

Subject: Re: [boost] tie alternative?
From: Pete Bartlett (pete_at_[hidden])
Date: 2008-10-27 18:47:07

>on Mon Oct 27 2008, "Michael G" <mgoldshteyn-AT-comcast.net> wrote:
>
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>> news:877i7uivdq.fsf_at_mcbain.luannocracy.com...
>>> ...
>>> However, we can make it much nicer, e.g.:
>>>
>>>  for (vertex_iterator pv,ve = xxx(pv,vertices(g)); pv != ve; ++pv)
>>>  {
>>>      ...
>>>  }
>>>
>>> My only problem is how to spell xxx.  The attached proof-of-concept uses
>>> operator%, but I don't feel particularly good about that choice either.
>>> Ideas?
>>
>> I would recommend one of the following, depending on your verbosity
>>comfort level. The vertical bar, | , denotes alternation:
>>
>> (get|as|to)_iterators
>> get_container_bounds

>Again, quite verbose.  But maybe BOOST_FOREACH is the right answer
>anyway; I don't know.

What with FOREACH's potential extra copying in the rvalue case and the
occasional desire to avoid a heavy include, I think there is room for this.
But OTOH I won't landgrab an operator overload for it.

So we want a short verb for it ... It's quite a lot like "tie" but not
quite. So some maybes:

tie //not caring that it's not really the same and assuming we have enough
wriggle room to avoid ambiguity in the U = pair<T,T> case

rtie //r is supposed evoke "right tie" i.e. RHS tie 

untie //in case you think it is actually more like the opposite of tie than
tie itself

split //keep the distance from tie

pry //short, "tie and pry" is quite rhythmical, supposed to be evocative of
"pry open"

By the way, your scrap paper code had a typo - the return type was intended
to be U. But in the envisaged use case of the for loop T has to equal U
anyway, so may be your subconscious was toying with the idea of making it a
template in only one type :-).

Pete