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

[Joel de Guzman]

Hi Raoul,

I've spent some time and perused your code. Nice!
Although our discussion has been rather sketchy at best,
I think I like the general direction this is leading to. Please
don't let me slow you down. You've done a nice work.
Keep it coming :-) !

Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
> "Joel de Guzman" <djowel at gmx.co.uk> writes:
> 
>> 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?
> 
> [taking a look at libs/python/test] Hey! You've already written some
> tests :-) I didn't know about these, but I guess I should have looked
> there automatically.
> 
> It turns out that the find() functionality needs some additional
> comparison operators in the element_proxy. I've added these, and the
> vector indexing tests now run without failure. It still requires some
> minor tweaks outside of the suite to make it work (i.e.
> register_ptr_to_python and implicitly_convertible).

I just had a problem with the find() functionality. The problem is that it
assumes that the element type of the container to be wraped has ==.
This is not always the case. Yet, I am not sure how to detect
that at compile time and disable the feature appropriately. I think a
basic problem with an all-in-one suite is that the requirements become
too broad. We really should break the thing down in smaller, easy to
manage pieces.

>> 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!
> 
> I've also been thinking about the slice return value problem, and I
> believe the best answer is to return a real Python list containing
> element proxies. My reasoning is that we can't return a container of
> identical type to the original, since it has value semantics and we
> need reference semantics to be at all Python-like. Unfortunately, this
> means that the following won't work:
> 
> # Given wrapped C++ function foo (std::vector<bar> const &)
> 
> foo (v)      # OK - called on std::vector<bar>
> foo (v[1:4]) # !OK - called on Python list
> 
> Then again, it also wouldn't work if v[1:4] was a wrapped
> vector<element_proxy>, so why not just use a real Python list and save
> some template instantiation work. Actually, I'm not sure whether
> creating a working vector<element_proxy> wrapper might not mean more
> programming work for us as well, in which case I'm definitely against
> it :-)

I am considering a slice_proxy<Container>. I am not sure how complicated
the implementation will be, but I think this is the right solution to the problem.
Schematically:

    slice_proxy
    {
        Container& c;
        Index from;
        Index to;
    };

As for the foo (v[1:4])  problem, you can have an implicit conversion from
a slice_proxy<Container> to a Container.

Thoughts?

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