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

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-14 07:40:19

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?
> 
> 
>>> Taking an example from MultiArray, if I have an 2x2 multidimensional
>>> array:
>>> boost::multi_array<int,2> A(extents[2][2]);
>>>
>>> and a template function that takes some Random Access Sequence:
>>>
>>> template <Sequence>
>>> process_sequence(Sequence& Seq) { /* ... */ }
>>>
>>> then I cannot pass this function the second "row" of my array using 
>>> the
>>> syntax:
>>> process_sequence(A[1]);
>>
>> Why can't you just return a const proxy?
>>
> 
> Here's the catch:  A multi_array has const and nonconst versions of the 
> various operations and I implemented my proxy objects to mimic that 
> behavior.  For example, operator[] returns a subarray if the original 
> array is non-const, but a const_subarray if the original array is 
> const.  Since I sometimes want the array to allow mutating operations 
> and sometimes not, I cannot merge the const and nonconst versions of 
> these operations in the proxies.  I need both const and non-const 
> versions.
> Thus:
> subarray const&
> and
> const_subarray&
> 
> behave alike.

But do they need to?  Why not have

  subarray const&

behave like

  subarray&

and

  const_subarray const&

behave like

  const_subarray&

??

>>   class multi_array
>>   {
>>       const mutable_proxy operator[](int);
>>       const immutable_proxy operator[](int);
>>       ...
>>   };
>>
>> Now mutable_proxy only needs one version of the array operators.
>> Couldn't that work?
>>
> 
> See my comment above.  

I don't get it yet.

> Also, is one of these member function 
> declarations missing a const qualifier? 

The second one.

> If so, then this is already 
> what I'm doing and it's not sufficient.

Did you notice the const-qualified return types?
Why is it not sufficient?

> I know that while working on multi_array, I had some discussions with 
> Jeremy about this and it didn't work for what I was trying to do.  That 
> was sometime around 2001 though, so the details are hazy. I've 
> unfortunately had trouble communicating my position, if only because 
> the details quickly fade from my memory each time the issue comes up.
> 
>> I'm not sure; have they used enough imagination?
> 
> Good question.  I've thought about this on and off for a while and I 
> have yet to come up with or hear of a solution.    I'm neither a 
> language lawyer nor a metaprogramming guru, so it's quite possible that 
> I'm overlooking something.  :)

Try to answer my questions above and we'll see.

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