Re: [Boost-users] Re: Boost.Python - implementing slicing on extension container class

From: Steve Horne (steve_at_[hidden])
Date: 2003-09-16 14:26:49

At 11:20 16/09/2003 -0400, you wrote:
>Steve,
>
>First, Boost.Python questions should go to the C++-sig
>(http://www.boost.org/more/mailing_lists.htm#cplussig).

OK - sorry for the confusion. I understand that Boost.Python users must be 
a rather specific subgroup of Boost users, but I had not realised that this 
was the wrong place to ask Boost.Python questions.

I guess I don't need to ask why my emails keep losing their subject line as 
I'm in the wrong place and may as well unsubscribe.

>Second, The current CVS has some excellent work on presenting C++
>containers as Python containers by Joel de Guzman and Raoul Gough (see
>vector_indexing_suite).  I really suggest you try this stuff; it could
>save you lots of code and will almost surely work better for you than
>what you've done by hand because it handles some very subtle issues of
>Python object lifetime and validity correctly.

Actually, while I could probably have picked up some useful tips and saved 
myself some time, I now have everything figured out that I need.

Also, as the containers I'm wrapping are *not* standard library containers 
but actually a replacement library I wrote, many of the things that would 
presumably get the biggest emphasis (e.g. the validity and lifetime issues) 
would simply be non-issues with my containers. The main motivations in 
writing the C++ library were basically that the standard library containers 
are too fragile, lack useful functionality that cannot reasonably be 
retrofitted, and probably (due to the red-black trees assumption of a 
constant-time memory access model which is decades out of date and ignores 
the everyday facts of caching and virtual memory) unnecessarily slow.

While I wanted the C++ containers to be fast and scalable, the main reason 
for writing them was because I wanted more flexibility, better safety, and 
more convenience. The fact that the 'iterators' are not invalidated when 
the container is updated, and keep track of the item they were left 
pointing to, is probably the single most important feature. The goals of 
flexibility, safety and convenience seem well suited to a scripting 
language such as Python, so it seemed sensible to give them a try in that 
context.

Using my containers, object lifetime and validity is already managed even 
in C++, so I really don't need to worry about it in Python.