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

[Raoul Gough]

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

> 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 :-) !

Thanks! I should have some more time for this in the next few days, so
I'll see what I can do.

>
> Raoul Gough <RaoulGough at yahoo.co.uk> wrote:
[snip]
>> 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.

I see. Unless there is some kind of template meta-programming magic to
detect operator==, we would need a manual switch. Maybe we could break
this down by introducing not only a container_traits template, but a
value_traits one as well. The container_traits could then make use of
value_traits<container::value_type> internally to figure out whether
things like find() are possible, and the client code could specialize
value_traits where necessary. In most cases, of course, the defaults
would work, but in special cases only minimal work is required for the
client code, since value_traits would probably be very simple.

I guess the next thing to do is pull some of the existing work
together, maybe adding the new value_traits template and a partial
specialization of container_traits for container_proxy. I'll try to
make some progress on this before the middle of the week.

One thing we haven't yet considered is support for different
conversion policies. Hopefully I'm not just being overly optimistic,
and we can retro-fit this later.

[snip slice discussion - see my reply to Dave's followup]

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