View mode: basic / threaded / horizontal-split · Log in · Help
April 11, 2008
Re: On the richness of C++
Sean Kelly Wrote:

> == Quote from Kevin Bealer (kevinbealer@gmail.com)'s article
> > Out of curiosity, what motivates your desire for placement new?
> 
> Constructing D objects in shared memory.  That's also an underlying
> reason why I added a way to override object monitors in Tango.
> 
> 
> Sean

I wondered about this myself -- at one point I sat down and designed a bunch of code
in C++ that used relative pointers and memory mapped areas.  The idea was to have
a complete set of tools for created "tied" containers and so on in memory mapped
files, so that you could create documents and random data structures without considering
the data format itself.

The relative pointer idea is that a smart pointer could be defined that actually stored the pointed to value minus the pointer's address.  This allows you to point to other objects in
the same memory mapped arena regardless of where it gets mapped to.  It's also nearly
free to use these because the address of the pointer being dereferenced is always itself
in a register, so the cost of dereferencing is exactly one subtraction with no IO overhead.

You can also use 32 bit pointers regardless of platform as long as your arena is <= 2GB,
but you need to worry about endianness.  Alternately, you could use 64 bit pointers with
a 32 bit arena# and 32 bit offset in that arena -- it's more flexible for multi-document systems but takes more computation.

Of course you need to redefine every type you use with this system -- even C++ classes that use allocator template parameters rarely come in a form that is templatized on smart-pointer type.  (And if you use virtual pointers, you need to do something about that -- I had some ideas but I never finished that part of it.)

Kevin
April 11, 2008
Re: On the richness of C++
== Quote from Kevin Bealer (kevinbealer@gmail.com)'s article
> Sean Kelly Wrote:
> > == Quote from Kevin Bealer (kevinbealer@gmail.com)'s article
> > > Out of curiosity, what motivates your desire for placement new?
> >
> > Constructing D objects in shared memory.  That's also an underlying
> > reason why I added a way to override object monitors in Tango.
> >
> I wondered about this myself -- at one point I sat down and designed a bunch of code
> in C++ that used relative pointers and memory mapped areas.  The idea was to have
> a complete set of tools for created "tied" containers and so on in memory mapped
> files, so that you could create documents and random data structures without considering
> the data format itself.
> The relative pointer idea is that a smart pointer could be defined that actually stored the pointed to value
minus the pointer's address.  This allows you to point to other objects in
> the same memory mapped arena regardless of where it gets mapped to.

It's a bit tricky, but so long as you map the file at the same address in every app using it
then you can actually use absolute addressing and have it work.  The tricky bit ends up
being making sure that the vtbl pointers are valid, etc.  I actually worked on a (patented)
object database type system that stores all of its data as memory-mapped C++ objects
which are used directly from their mapped location using such tricks.  It's unbelievably
fast and does all the mapping and unmapping automatically as the applications run.
I'd do something comparable for D but for my exposure to the project--it's just too
much of an IP risk, even not considering the patent.

> Of course you need to redefine every type you use with this system -- even C++ classes that use allocator
template parameters rarely come in a form that is templatized on smart-pointer type.  (And if you use virtual
pointers, you need to do something about that -- I had some ideas but I never finished that part of it.)

In C++ you can supply a custom allocator that typedefs those smart pointers as the
pointer type.  As much as those allocators complicate container design in C++, they
offer an incredibly flexible design.  If you wanted to, I suspect you could even make
an STL allocator that used a SQL database for storage.


Sean
Top | Discussion index | About this forum | D home