Raoul Gough <RaoulGough@[...].uk>  writes:

> > " It is designed to wrap C++ interfaces non-intrusively, so that you should 
> > not have to change the C++ code at all in order to wrap it, making Boost
> > Python ideal for exposing 3rd-party libraries to Python.". 
> 
>  Personally, I prefer the smart pointer approach - "as safe as
>  possible, but no safer" :-) I take your point, though.

Compromises are possible.  I think it's reasonable for someone to
want a safe container which doesn't provide the illusion of value
independence:

        > >> c = get_container()
        > >> x = c[0]
        > >> print x
        'foo'
        > >> c[0] = 'bar'
        > >> print x
        'bar'

But the full illusion should be an option, IMO.

> > Forcing the client to wrap containers of shared_ptr goes against
> > this goal.  As a matter of fact, what actually spurred the
> > development of the indexing suite was because I needed to wrap some
> > special vectors of objects. It is out of the question to go
> > modifying the C++ code.
> 
>  Well, my concern is to do with the complexity of the support - it
>  seems to require hooks throughout all of the code that modifies the
>  container. Maybe it would be possible to create a "container proxy"
>  that emulates the vector interface, and use:
> 
>  indexing_suite <container_proxy <std::vector<MyType> > >
> 
>  Thus encapsulating the proxy code. I think this would localize the
>  code much better, if it is possible to do.
> 
>  Another concern about this - have you considered cases where C++ code
>  accesses the raw container (i.e. without going via the indexing
>  suite)? e.g.
> 
>      val = c[i]
>      cxx_function(c)
>      val == c[i]  # ??
> 
>  where cxx_function might (from C++) insert something into the
>  container. If I understand correctly, doing an insertion via the
>  indexing suite would notify the proxy when it needs to update its
>  index. I think that means that raw C++ code that modifies the
>  container would cause problems.

We're aware of this.  In that case we at least do range checking to
make sure it can't crash.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig