Boost logo

Boost :

From: Olaf Krzikalla (krzikalla_at_[hidden])
Date: 2007-03-19 12:24:36


Hi,

Tom Brinkman wrote:
> Get the reader excited about why boost::intrusive is "cool".
You know Alan Murta's GPC? It is fast. Really fast. It's well-written C.
But with the boost::intrusive toolkit you easily can remake it in C++.
Perhaps even faster (with less memory allocations). And with a lot less
lines of code. Very well then. Readable C++ becomes faster than C. Cool ;-)

Seriously spoken, there are a lot of complex (geometric) algorithms
operating over multiple sequences of the same set of objects. And of
course all these algorithms needs to be fast. If you have 10.000,
100.000 or even more objects, the memory allocation done by
std::list<T*> is not suitable any more. And if there are a lot of
insertions and erases amidst the sequence std::vector<T*> is not
suitable too. In this case you should be able to go one step down and
use the fundamental container algorithms more directly. boost::intrusive
  gives you that option.

There is another container (boost::multi_index) which can manage
multiple sequences over one set of objects. It is safer to use but IMHO
it's less flexible than boost::intrusive (AFAIK each object in a
multi_index_container needs to be stored in every sequence of that
container). Actually I think, that boost::multi_index easily could (and
maybe should) be built on top of boost::intrusive.

Regarding the unsafe programming thingy: I'm unsure about the term. What
means "unsafe programming"? You have to keep in mind the lifetime of the
objects stored in an intrusive container. Just like you have to keep in
mind the lifetime of the objects stored in a std::list<T*>. However I
admit, that 'intrusive containers' are perhaps merely a wrong and thus
misleading name. In turn this would explain the "unsafe programming"
feeling. Maybe they would be better labeled with something like
'intrusive sequences'. But I wouldn't change it no longer.

Best regards
Olaf Krzikalla


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk