Re: [boost] Proxy indirect container adaptor: 4 claims

From: Jesse Booher (jbooher_at_[hidden])
Date: 2004-02-26 18:25:09

>> Christian Engström <christian.engstrom_at_[hidden]> writes:
> 1) By using a proxy object, which is essentially a shared_ptr with the 
> pointer arithmetic removed and with the comparison operators redefined 
> to compare the elements, and storing such proxy objects in an STL 
> compatible container, we can use all the algorithms in the STL on the 
> Container< proxy<T> >, and get the same result as with a Container<T>. 
> (This works even with the standard STL iterators and in the absence of 
> any of the other components of the package, so it could be used as a 
> standalone feature if desired.)

> 2) By making proxy<T> implicitly convertible to T&, a proxy<T> can be 
> used (almost) as a T when it comes to assignments and argument passing. 
>  In the situations when it doesn't work, such as if a function takes a 
> U argument and was expecting another user-defined conversion from T to U 
> to let it handle a T arguments as well, the compiler will generate a 
> type error.

> 3) By letting proxy_container define an extra variant for each member 
> function that would normally take a proxy<T> argument, and letting the 
> extra variant accept a T instead, we complete the last part of the 
> symmetry with direct containers as far as entire T objects are concerned.

> 4) By defining operator-> in for proxy_container's iterators to do a 
> double dereferencing, the meaning of that expression remains the same 
> for a proxy_container iterator as it would for the direct container 
> iterator.  operator* keeps its normal semantics and does a single 
> dereferencing.  This definition is necessary to keep Claim 1 valid, and 
> to keep the proxy_container working as one would expect from an indirect 
> container in general.

Your Proxy discussion has intrigued me and I took a look at the issue thinking I could
come up with a quick solution.  The problem is much more subtle than it appears at
first blush, however.  The main problem is that existing container classes have a fixed
concept of what types of iterators that they process.  There is no way to tell std::vector
that its begin() method should return anything other than std:vector::iterator.  If there were
an easy way to change this behavior then your proxy problem would become trivial.

Imagine for a moment that Iterator Types were part of vector's template arguments then
vector<T,  allocator<T>, vector<T>::default_iterator, vector<T>::default_reverse_iterator> and
vector<S,  allocator<S>, indirect_iterator<vector<S>::default_iterator>, 
indirect_iterator<vector<S>::default_reverse_iterator> >, with S being shared_ptr<T>, would be
duals the first for direct access and the second for proxy access.

Wonder what it would take to make this happen.  Could perhaps be a solution worthy of standards submission.

Regards,
Jesse Booher