Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-06-10 02:40:47

David Abrahams writes:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>> Yes, it's in the 'make_transform_iterator's current semantics. I
>> should have phrased the above as
>> I would say 'make_transform_iterator' should by default return a
>> 'transform_iterator' which 'operator*' always returns by value
>> and there should be an explicit notation to request by reference
>> semantics (if it's compatible with the transformation function's
>> return type).
> Okay, so the next question. Do we
> a. Pick a new name for this make_transform_iterator to avoid
> breaking existing uses
> b. Change the semantics to un-break older uses (and
> if so, what do we call the current semantics?)
> c. Something else?

I'm strongly in favor of (b); in case I didn't make myself clear in, though, I
maintain that relying on the specific transformation function's
signature to get a particular dereference behavior that happens to
work now -- that is, the current semantics, -- in majority of cases
simply puts in a maintenance time bomb. Furthermore, I might be
missing something, but I don't see a single compelling use case for
this behavior except that "we can do that". You know when you want
your iterator's 'operator*' to return by reference, and once you've
established that, you want the compiler to enforce it for you. So, my
proposal would be:

1) Revert 'make_transform_iterator' to pre-1.32 semantics (return by

2) Introduce 'make_reference_transform_iterator' which would
   explicitly ask for return by reference and enforce the
   corresponding signature of the transformation function.

3) Leave 'transform_iterator' intact, allowing for unforeseen use
   cases which would benefit from its current default behavior.

Aleksey Gurtovoy
MetaCommunications Engineering

Boost list run by bdawes at, gregod at, cpdaniel at, john at