[C++-sig] Re: Support for Indexing and Iteration Safety

[David Abrahams]

Mike, please take this discussion to the C++-sig...

"Mike Rovner" <mike at bindkey.com> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:u65nv6j6h.fsf at boost-consulting.com...
>>      1. Unlike most of the other operators, which can be wrapped using
>>         "self op other", there's no easy way to wrap the indexing
>>         operator.  You end up having to write your own __getitem__
>>         and __setitem__ functions.
>
> I don't see any _general_ way to automate that, however it might be worth
> for STL containers.
> Probably simplistic approach will do; any advanced person can do that
> himself and starters will benefit right out of the box.
>
> inline void IndexError()
>   { PyErr_SetString(PyExc_IndexError,"Index too large");
> throw_error_already_set(); }
>
> template<class T>
> struct std_item
> {
>   typedef typename T::value_type Value;
>
>   static Value const& get(T& x, int n) {
>     if( n<0 ) n+=x.size();
>     if( n<x.size() && n>=0 ) return x[n];
>     IndexError(); }
>
>   static void set(T& x, int n, const Value& val) {
>     if( n<0 ) n+=x.size();
>     if( n<x.size() && n>=0 ) x[n]=val;
>     else IndexError(); }
>
>   static void del(T& x, int n) {
>     if( n<0 ) n+=x.size();
>     if( n<x.size() && n>=0 ) x.erase(&x[n]);
>     else IndexError(); }             ^^^^^
> };                                   ^^^^^
                                   Doesn't work (not an iterator).

I have something a little less simplistic in mind.  Why shouldn't
everyone benefit? ;-)

>>      2. You also have to implement the code which raises an exception
>>         if the index is out of range or the key is not found (in case
>>         you're implementing a mapping).  If you forget, your extension
>>         class is prone to crashes and accessing invalid data.
>
> Ditto.
>
>>      3. Even if you get that right, you may still be prone to crashes.
>>         Suppose you're wrapping a std::vector<SomeBigObject>.  If you
>>         want to support syntax like:
>
> Let's return to basics. What is foo[10]? In C++ it's a memory chunk

I think you mean an lvalue.  That really depends what foo is.  See
vector<bool> for example.

> in Python it's an object.  To overcome that difference I propose to
> introduce differenciation in wrapping, a la it is in Python: there
> are tuples and lists; mutable and immutable. So let user decide what
> he wants out of foo[10] - mutable object (a copy), or readonly - an
> inplace reference.  

Of course the user will have a choice; she already does, using call
policies.  I take choice for granted.  The problem is that an "inplace
reference" as it stands now is not safe, and sometimes you need an
inplace reference.

> Again please don't argue about general ineffiency, IMHO better safe
> than sorry ..egh crash.  

Some people care about efficiency.  If their wrapped program is too
slow we may as well have not provided the wrapper in the first place.
But anyway, efficiency is only one of two obvious reasons to use an
"inplace reference", so it doesn't really matter if you discount that
as an argument.

> I take for granted that some _simple_ enought way to override that
> default behaviour with custom is provided.
>
>>      4. Similar problem with exposed iterators:
>
> Same.

You are not addressing the problem.  The question is:

    is it acceptable that Python users of extension classes should be
    subject to unpredictable behavior and/or crashes when using
    wrapped arrays, mappings, and iterators?

I think the answer should be a loud "no", but from the lack of a
general outcry it seems I might be wrong.

>> These problems are not vector-specific.  I have some ideas about
>> addressing them but I'm not sure how far to go, and first I want to
>> know how many people care.
>
> My 0.02. Hope I made my point clear.

Not really.  The clearest message I can discern is "there's really not
much of a problem". Is that really what you're saying?