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

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-20 17:54:40

Ronald Garcia wrote:
> Sorry that it has taken me another week to reply to this one.  I've 
> been up to other things and not had time to think about it.
> 
> 
> On Dec 14, 2004, at 7:40 AM, David Abrahams wrote:
> 
>> Ronald Garcia wrote:
>>> Howdy again,
>>>
>>>
>>> On Dec 13, 2004, at 10:49 PM, David Abrahams wrote:
>>>
>>>> Ronald Garcia wrote:
>>>>>
>>>>> ...
>>>>> Around here (the Open Systems Lab at Indiana University), I've been
>>>>> arguing against this property of C++ for a long time, specifically
>>>>> that
>>>>> the language does not allow you to bind temporary to a non-const
>>>>> reference.  I am under the impression that this behavior is meant to
>>>>> "protect"  the programmer from making certain mistakes, but the 
>>>>> grave
>>>>> downside to this is that it also prevents a library writer from 
>>>>> using
>>>>> proxy objects to mimic reference semantics.
>>>>
>>>> The only case I can think of where that's true is when the reference
>>>> type is the same as the value type.  If we allowed operator->
>>>>
>>> Is this a complete thought, or am I missing something?
>>>
> I'm still wondering where the above comment was going.  What is the 
> rest of the sentence that starts "If we allowed operator->..."?

I think I was going to say that if we allowed it to return a non-const
pointer when is_same<reference, value_type>::value == true, that would
handle the cases in question.

>> But do they need to?  Why not have
>>
>>   subarray const&
>>
>> behave like
>>
>>   subarray&
>>
>> and
>>
>>   const_subarray const&
>>
>> behave like
>>
>>   const_subarray&
>>
> 
> I had thought about this at the time and came to the following 
> conclusion (modulo the fog of time since I made the decision):
> 
>  From my perspective, it seems that if a template function has a 
> signature such as:
> template <Container>
> void my_function(Container& A);
> 
> Then that function expects to receive a mutable container type.  In the 
> case that a function expects to receive an immutable container, the 
> signature is likely to be:
> 
> template <Container>
> void my_function(Container const& A);
> 
> IIRC some templated functions are overloaded as above specifically to 
> handle these two cases.

Yes.  Those functions are, in my experience, always used to expose
references/pointers that have the right mutability.  For example,

  template <Container>
  typename Container::value_type& operator[](Container&);

  template <Container>
  typename Container::value_type const& operator[](Container const&);

They _never_ have different operational semantics.  There are several
ways to handle that with const proxies.  For example,

  const_subarray<T>::value_type

could be the same as

   subarray<T>::value_type const

> I concluded that if I chose the design you describe above, namely that 
> "subarray const&" behave like "subarray&" and "const_subarray const&" 
> behave like "const_subarray&", then I would likely violate the 
> expectations of a template function.  Objects of type subarray , the 
> mutable reference proxy, would be passed to the second function above.

I don't think that's a big deal.

> Suppose for a moment that a one-dimensional subarray is passed to the 
> above function.  Using the above design, A::operator[] would return a 
> mutable reference to an underlying data element, though a const 
> reference to the underlying data might have been expected.  That 
> mutable reference could be accidentally mutated (for example, by a 
> similarly overloaded function that mutates in one case and does not in 
> the other).

I don't think so; see above.

> In summary, I chose to have subarrays respect the constness built into 
> the language as well as the constness imposed by the choice of proxy 
> object (const_subarray or subarray).
> 
> To the best of my memory, this was my thinking at the time.

Understandable, but perhaps this an example of the insufficient
imagination I was alluding to.

The way I see it, you're asking me to sacrifice the ability to provide
const-correctness for convenience, and I'm suggesting that no matter how
ugly it may be, there's a way to keep everything safe within the current
language.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com