From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2001-11-20 12:05:24
Funny you should ask...
I have implemented a B+Tree class which (mostly) emulates the std::map interface, and which supports huge content with
easily constrained use of memory.
As for other container types, I would think std::deque would be quite ammenable to a paged implementation which could
support very large content, and certainly std::list (and the relatives of std::map) would be.
I'd be interested in having containers such as this one in Boost - I'm willing to upload the code if there's sufficient
interest, but I must preface that with a caveat that the code is IMO far from Boost quality at this point in its
One major compromise which I made in my paged_map implementation is that it supports only POD classes for the key and
value types (btw - has anyone ever come up with an is_pod<T> solution?).
On the subject of building a huge-vector with just a custom allocator, doesn't the (proposed?) guarantee that &v
yields a pointer to contiguous memory pretty much eliminate the custom allocator solution?
----- Original Message -----
Sent: Monday, November 19, 2001 10:38 PM
Subject: [boost] huge container types?
> Has anyone tried implementing something to support huge containers
> that couldn't possibly fit into memory (even using swap space). I'm
> not talking about sparse arrays, I mean where you actually need 8Gig
> of space to store information that you are working on actively, and
> need to be able to access it transparently without caring whether it
> is stored on disk or in memory (so that, for instance, you can
> dynamically adjust how much is stored in memory and how much on disk).
> 8 gig is just about enough to hold the matrices necessary to do
> certain forms of boundary element and finite element analysis on
> complex input models, so this is not a purely theoretical need!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk