Boost logo

Boost :

Subject: Re: [boost] Boost library submission (poll for interest)
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-06 12:23:53


while we're discussing persistent containers, could you please have a look at
the following patch to Boost.Intrusive and tell me if you'd be ok with these

The containers described here require the patch:

the patch does:
 - remove some assumptions/restrictions, which should not have any effect on
existing code using Boost.Intrusive (e.g. the assumption that
Container::pointer is always a C++ pointer)
 - expose the container's header/root node through a "protected:" interface to
its derived class.

the changes are currently only made to those Boost.Intrusive containers that I
use, but if you want them uniformly applied to all containers I can do that.

thank you,

Am Wednesday 06 January 2010 17:18:50 schrieb Ion Gaztañaga:
> El 06/01/2010 2:18, Bob Walters escribió:
> > On Jan 5, 2010, at 9:08 AM, Ion Gazta?aga<igaztanaga_at_[hidden]> wrote:
> >> I think most in-memory databases use T-trees as main containers. I plan
> >> to add them as Interprocess containers for late 2010, but of course,
> >> that will depend on my free time. With those containers, we could speed
> >> up searches and waste less space.
> >
> > Would the interface remain identical to map?
> > The current 'trans_map' can be revised slightly so that it would be
> > a transactional wrapper for any map implementation, leaving the
> > internals of storage to the implementation. Taking advantage of a
> > T-tree variant would then be very easy to accomplish.
> Yes, it would be identical, except that you have different iterator
> validation guarantees, because a T-tree instead of nodes has arrays and
> that requires some copying (or moving) when rebalancing. So iterators
> might be invalidated when inserting or erasing. Is that a problem for
> your library.
> Best,
> Ion
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at