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

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-13 22:49:03

Ronald Garcia wrote:
> Howdy,
> 
> Dave sent me a forward to this conversation some time ago and I have 
> finally made the time to catch up on the conversation and contribute my 
> two cents.   The issues that Tobias describes regarding operator-> are, 
> I believe, exactly the same issues I encountered while implementing 
> Boost.MultiArray.
> 
> To use an earlier version of iterator adaptors, I had to supply a 
> modified  copy of the library as part of MultiArray's implementation.  
> Using the more recent version of iterator adaptors, I simply had to 
> implement my  own operator->() member function and operator_arrow_proxy 
> object.  Clearly I can implement the behavior I want using the library 
> as-is.
> 
> The question of interest then seems to be the following: Should 
> iterator adaptors somehow more explicitly take my and Tobias' 
> implementation needs into consideration?  Perhaps the library's default 
> behavior when Reference is not a true reference type should be changed; 
>   Perhaps a FAQ entry in the documentation would suffice.  Since I can 
> make my library work correctly today with little pain or code 
> duplication, I'm not particularly passionate about this case.
> 
> With respect to the greater language issue, let me respond to an 
> earlier statement by Dave:
> 
> "If iterator_facade handed you a pointer to non-const value_type, it
> would  allow you to modify this temporary, which would then disappear.
> We don't do that for the same reasons the language won't bind a
> non-const reference to a temporary."
> 
> 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->

> 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?

> because the return type of multi_array::operator[]() is an object of 
> type multi_array::subarray.  The whole purpose of the subarray is to 
> behave as though it were a nested array within the multi_array.  Bear 
> in mind that multi_arrays are not implemented using nested arrays:  the 
> internal data is stored as a contiguous heap-allocated array.  You 
> could argue that the entire point of the MultiArray library is to allow 
> one to avoid implementing multi-dimensional arrays  using such a nested 
> form  (i.e.  std::vector<std::vector<int> >).
> 
> In order to make MultiArray work, it must return a proxy object that 
> implements const and nonconst versions of the array operators.  

  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?

> The 
> subarray operators manipulate the data stored in the original 
> multi_array that created the original subarray.
> 
> In fact, the Matrix Template Library (MTL) ran into the same problem. 
> The library often creates a "view" of a matrix as an argument  to a 
> subsequent  function.  But again, if the subsequent  function takes its 
> argument by reference (which it should if the argument is used as an 
> "out parameter"), then the result is a compile-time error.  What was 
> their solution?  I hate to admit this: const_cast.

Did someone think about returning const proxies?

> Let's take a step back for a moment. Why is it okay in the language for 
> me to create a temporary object and immediately call a non-const member 
> function on it, as in:
> A().member_function();
> 
> But it's not okay for me to pass a temporary object to another function 
> that in turn calls that same member function, as in:
> 
> template <class T> call(T& x) { x.member_function(); }
> 
> call(A());

You may note that I'm an author of a major proposal to allow templated
references to bind to non-const rvalues.

> I've been convinced by others that if the move semantics proposal is 
> accepted into the language, it will take care of this issue.

Bingo.

> Perhaps iterator_adaptors should mimic the behavior of C++ as it stands 
> for the purpose of consistency, but I'm not convinced that this 
> property of the language does much for safety. It is clear to me, 
> however, that it hinders library developers who hope to mimic reference 
> semantics with proxies.  

I'm not sure; have they used enough imagination?

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