Re: [boost] huge container types?

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

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[0]
yields a pointer to contiguous memory pretty much eliminate the custom allocator solution?

-cd

----- Original Message -----
From: <dylan_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 19, 2001 10:38 PM
Subject: [boost] huge container types?

> Hi,
>
> 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!