Boost logo

Boost :

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.

Jesse Booher

Boost list run by bdawes at, gregod at, cpdaniel at, john at