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

Raoul Gough RaoulGough at yahoo.co.uk
Mon Aug 18 14:49:46 CEST 2003


[cc'd to Joel in the hope that he will help out]

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

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> OK, I've added len and read-only indexing to boost::python::range,
>> dependant on iterator type. I've posted my current progress to
>> http://home.clara.net/raoulgough/boost/ - any comments are
>> welcome. There is a test script (currently stand-alone) and no docs
>> yet. I'll wait a few days to see if anybody suggests any changes
>> before advancing.
>
> One other point: I notice you're wondering whether to support slices;
> probably you should have a look at Joel's recent indexing suite work.
> Maybe once we start to get into range-as-iterable instead of
> -as-iterator we should also be handling some of the object lifetime
> and iterator validity issues.  If this seems reasonable to you, you
> probably ought to talk it over with Joel.

I've had a chance to look at Joel's indexing_suite, and there should
be quite a lot of overlap in the functionality between indexing_suite
and the extended iterator_range. I've been thinking about how to
provide the range-as-iterable support within the indexing_suite
framework, but it looks like there would have to be some changes to
the base classes.

I'm basically considering an indexing_suite-derived class template
that would use two iterators for construction and provide only the
relevant support functions (from __iter__ alone for input_iterators
through to __getitem__ and __setitem__ for random access iterators
with non-const value types). The problem is that the indexing_suite
base classes assume that all container functionality is always
present, all the way up to __delitem__ (impossible for
iterators). Thus, it is currently unsuitable for use with iterator
pairs, especially if one considers const_iterators. For instance, the
following doesn't come close to compiling:

  boost::python::class_<std::vector<int> > ("Vector")
    .def (boost::python::vector_indexing_suite<std::vector<int> const>());

For obvious reasons (note the const qualifier). I haven't got far
enough to see how many changes it would require to allow containers
with less functionality than is currently assumed. Maybe Joel has some
comments about the feasibility of this idea?

-- 
Raoul Gough
"Let there be one measure for wine throughout our kingdom, and one
measure for ale, and one measure for corn" - Magna Carta





More information about the Cplusplus-sig mailing list