Re: Customized Allocator (on disk)

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Mon, Dec 03, 2001 at 09:19:44PM -0800, Reza Roboubi wrote:
> Phil Edwards wrote:
> > It's lacking from the standard because the standard doesn't say anything
> > about disks, hashes, or how to access them.  It doesn't even assume that
> > "files" exist.
> 
> I thought that the STL standard has template objects like "map," "hash," and  the
> like.  Why do you say that STL says nothing about hashes??

Because they don't.  Those are extensions, not standard members.


> This is not about writing any routines for the GNU implementation to access the disk or
> any other media directly.  Although it is about making it possible for the _user_ to do
> this.  The user should be able to create "persistent allocators" for any media (disk,
> raw partition, ...), exactly as I believe Benjamin is pointing out.  Eventually, I am
> thinking of disks, and if I write such a "persistent allocator" (for disks) myself, it
> will be submitted for addition to the GNU STL.  But the main QUESTION is:  what are the
> additions that one must make to the actual objects(hash, map, etc) to make this
> possible.

That's an interesting project.  You could probably get away with not having
to change the containers at all, and only provide a different allocator.
Restoring the state of a container from the saved persistent allocator would
be the difficult part, but I haven't thought about it as much as you have.


Anyhow, I'll just make some comments offhand:

> I believe that the Allocator objects are required to provide an abstract "Pointer"
> type.  When we pass an Allocator object to a template object like the Hash, the Hash
> template is instantiated into a real hash object which depends on the abstract
> "Pointer" type supplied by the Allocator.  In other words whenever the hash wants to
> write somewhere, it does something like:
> p[i + 4] = 55; where the Pointer Type p overrides the [] operator of course.
> 
> I believe that is how it is implemented in Dinkum.  But  again, I have not yet read the
> GNU code.

More or less.  The "pointer" supplied by allocator classes doesn't have
to be a separate class, of course.  Most of the time, it's just a typedef.

Early implementations of the STL would make the allocators depend on
knowledge of the specific pointers types.  The version in libstdc++-v3
does not.


> As long as a "Hash" object depends on the 32
> bit integer, it is impossible to place it into a 50 GB partition and make proper use of
> the whole 50 GB.  So the main issue is that the actual __template_objects__ (Hash, Map,
> etc) in the GNU implementation of the STL  must be changed.  They must depend on an
> abstract notion of "Integer" which is not limited to the 32 bit range.

The hashtable extension in libstdc++-v3 does not depend on an integer being
any particular size.  As far as I can tell, it doesn't depend on integers
behaving in a particular fashion at all.

Maybe this is specific to Dinkumware?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams