$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
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