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

Raoul Gough RaoulGough at yahoo.co.uk
Sat Aug 30 15:17:45 CEST 2003


"Joel de Guzman" <djowel at gmx.co.uk> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
[snip]
>> I think that means that raw C++ code that modifies the container
>> would cause problems.
>
> Yes, I am aware of that. That's a caveat. Before, the indexing_suite 
> goes public, I have to provide a notification function that one needs 
> to call in such cases. Right now, I am not sure about its interface.

Maybe using the container wrapper (below) would solve this problem
fairly neatly, since the C++ code has full access to the wrapped
container.

>
>> So what do you think of the idea of providing a proxy-container-
>> wrapper, instead of integrating the proxy support directly into the
>> indexing suite? C++ code would then be aware (and have direct
>> access to) the wrapped container, and it might significantly
>> simplify the internals of the indexing suite.
>
> Looks like a good idea. Feel free to try it out. I'm all for further
> refactoring.

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>

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:

    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).

Anyway, new code is available from my website:

http://home.clara.net/raoulgough/boost/release.tar.gz

I'll have another go at updating the boost-sandbox when possible
(forgetting about my earlier botched attempts).

Ultimately, it would be good to do away with the implicit conversions
that the element proxy provides, but I'm not sure that this is doable
(and would certainly require special case code in the interfacing
suite).

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)





More information about the Cplusplus-sig mailing list