[Boost-users] Re: [iterator] iterator_facade operator-> pointee always const

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-12-06 07:53:16

David Abrahams wrote:
> Tobias Schwinger wrote:
>> I see - thanks for your detailed reply.
>>
>> When using proxy classes as references the assumption that 
>> modifications of a temporary object are lost at the end of this very 
>> object's lifetime does not apply 
> 
> 
> It most certainly does apply.  There may be some cases in which it 
> doesn't, but the usual case is that it does.
>

Writing "proxy class with reference semantics" would have been more 
precise, I figure.

>> - modification of the proxy object actually means changing the stored 
>> data internally referenced by it.
> 
> 
> Normally the reason for a proxy is that there isn't any "stored data 
> internally referenced by it."  If there's a persistent lvalue, why not 
> just return a real reference instead of a proxy?
> 

Because I have to change its interface.
In my particular case the persistent lvalue is of array type.

>> In this case it would be OK if not preferable to have operator-> 
>> return a pointer to non-const...
>>
>> Is there any way to achieve this (besides hand-coding the whole 
>> iterator) ?
> 
> 
> Just hand-code your own operator->.
> 

OK - that's what I did, for now.

>> And why does operator* give me a mutable (temporary) object then, by 
>> the way ?
> 
> 
> It is assumed that if you passed non-const R for the reference type, you 
> are trying to make a writable iterator, and R will have a (usually 
> non-const) assignment operator that takes a value_type argument.  If we 
> returned a const object, it would be impossible to write
> 
>    *p = x;
> 

If the expression

   *p

gives me a temporary object with no reference (write-through) semantics 
it does not make sense to write to this temporary by writing

   *p = x;

according to your above rationale, does it ?

Same goes for:

   (*p).mutator(value);

and

   p->mutator(value);

..and I can't imagine there is a user who would seriously complain that

   pointer ptr ( i.operator->().operator->() );

gives an invalid pointer ;-).

Am I missing something ?

--
Tobias