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

[Raoul Gough]

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>>
>> 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.
>
> Yup.  This is all starting to sound a lot like Alexander Nasonov's
> dynamic_any.

I've just had a quick look at dynamic_any, and it looks like it does
provide similar proxying features. Were you thinking that we could
use it in our implementation?

I wonder whether dynamic_any could be refactored to separate the
proxying and the "any object holder" facilities? Maybe a smart
reference that handles function forwarding could be treated as a
separate facility of its own, something like boost::shared_ptr except
that it pretends to *be* the referant object, instead of like a
pointer to it. This is essentially what the element_proxy has to do
for the indexing suite, except that it's currently all hard-coded.

For the moment, I prefer the traits approach rather than the typelist
that dynamic_any seems to use. In any case, we would still need some
kind of decision facility to figure out whether to .def("find"), for
example.

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