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

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-16 15:11:40

Steve Horne <steve_at_[hidden]> writes:

> 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.

Fascinating.  Submitting these to Boost, perchance?

> 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.

I guess I'll have to trust you on that one.  It's hard to see how you
can accomplish your goals of optimizing speed and safety at the same
time.

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