[C++-sig] Re: Adding __len__ to range objects

Joel de Guzman djowel at gmx.co.uk
Wed Sep 3 02:39:17 CEST 2003


Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> "Joel de Guzman" <djowel at gmx.co.uk> writes:

> Well, I've had a go anyway. I've produced a container_proxy template
> that wraps a random-access container and provides access via element
> proxies. The element proxies provide an implicit conversion to the raw
> value type, and also a constructor from the raw value type, which
> means that it works with an unchanged[*1] vector_indexing_suite as
> follows:
> 
> vector_indexing_suite<container_proxy<VectorType>, true>

This is great! Did the current tests pass with the new code?

> i.e. the wrapped vector with no proxy. This is functionally more or
> less equivalent to vector_indexing_suite<VectorType>, i.e. the raw
> vector *with* the proxy helper.
> 
> [*1] Actually, it does require a minor patch to make
> vector_indexing_suite use the container's reference typedef rather
> than data_type &
> 
> Note that I say "more or less" equivalent, since there seems to be a
> bug in the existing proxy support. Using vector<IntWrapper>, where
> IntWrapper is a simple int holder with optional tracing, the following
> snippet doesn't work correctly:
> 
>     copy = v[1]
>     print "copy is %s, v[1] is %s" % (copy, v[1])
> 
>     v[1] = IntWrapper (5)
>     print "copy is %s, v[1] is %s" % (copy, v[1])
> 
> Sample output:
> 
> copy is 3, v[1] is 3
> copy is 5, v[1] is 5    # Wrong - copy should remain unchanged
> 
> The container_proxy wrapper fixes that problem (whatever it is,
> probably minor) but doesn't fix the following additional problem, that
> both versions exhibit:

Indeed. It's nice to hear that container_proxy fixed this.

>     slice = v[1:2]
>     print "slice[0] is %s, v[1] is %s" % (slice[0], v[1])
> 
>     v[1].increment()
>     print "slice[0] is %s, v[1] is %s" % (slice[0], v[1])
> 
> Sample output:
> 
> slice[0] is 5, v[1] is 5
> slice[0] is 5, v[1] is 6  # Should be slice[0] is 6, v[1] is 6
> 
> This may be a fundamental problem with how slices are returned.
> Compiler is gcc 3.3.1 (mingw special 20030804-1).

Right. slices are currently returned by value. I guess this is another
area to be explored. I think I know how to deal with it. Let's do
it when we refactor the slicing stuff. I think this is a good start. There
are lots of things to do and I certainly am glad that you can help. I've
already been bitten by the wholesale approach of the current indexing
suites (more on that later) that I really need to break it up sometime
soon!

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net





More information about the Cplusplus-sig mailing list