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

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

> "Joel de Guzman" <djowel at gmx.co.uk> writes:
>
>>> 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.
>
> Consider whether this might be a way to save on template
> instantiations:
>
>     slice_proxy
>     {
>         object c;
>         object from;
>         object to;
>     };
>
> Remember, the container is already wrapped into a runtime-polymorphic
> object ;-)

I already considered and had to reject an approach like this.
Actually, I was thinking of using an iterator pair, but the problem
would be the same. A slice on this basis will be in error as soon as
an insertion or deletion occurs within the [from,to) range in the
original container, since the value lookup is deferred until elements
are accessed in the slice. To function correctly, the slice must
contain proxies for each element in the range _at the time the slice
was created_, so the proxies can track their values' movements during
inserts, erasures and overwrites. I currently like the idea of
returning a Python list of element proxies, since it saves code and
template instantiations.

Possibly a wrapped std::vector<element_proxy> with a suite
specialization would be better than a Python list, but I'm not sure
exactly what the pros and cons would be.

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