|
Boost : |
From: Jurko Gospodnetic (jurko_for_boost_at_[hidden])
Date: 2004-11-12 05:33:47
Hi Ion.
> Although so far only two people consider this library interesting.
Actually I'd be most interested in such a library. I at the
moment use my own solution for the same problem. I ran into
the same trouble you describe in your documentation but did
not get a chance to dig in so deep as I had a real-world
problem to solve in a real-world time frame :-))).
I did create a SharedMemory object which works, together
with my SharedMemoryId objects which are actually offset
based pointers that can be stored inside the SharedMemory
area. (Can't tell you how much I hate it when I get sloppy and
store a standard C++ reference in there only to find it is not
usable from another process. :-)))
My SharedMemoryId objects (actually called RepositoryId
and WriteableRepositoryId as the my model is pretty domain
specific) use an offset from the start of their SharedMemory
area and when you use them you need to specify which
SharedMemory object they relate to. I like your design with
an offset from their own address much better as that would
allow my * and -> operators to not rely on one global
SharedMemory object (which was enough in my case). And I
guess having a larger generic ptr that can be 0, and a smaller
non-null one is a small-enough price to pay (much better than
my relying on a global shared memory object when using
standard C++ dereferencing operators).
I did not implement any smart memory allocation schemes as
my shared memory space was only allocated and never needed
to be deallocated. I use a placement new operator (as in
'new (someSharedMemoryArea) int(5)') which just stores the
object on the next available location in the shared memory area,
and the memory allocation information is not shared so only one
user allocates the memory after which it allows read-only access
only. Unfortunately this also prevents me from directly using any
'smarter' data structures there, like strings or vectors, that
sometimes need to reallocate their storage space.
As for the standard C++ library containers - I tried the
allocator approach and ran into the same allocator problems
you encountered. In the end I just needed a list structure so I
rolled out my own and made it an STL compatible container
so that it can be used with standard C++ library algorithms.
Hope you see you're not alone out there... like I thought I
was when I did this... :-). If you need any help please just
holler... I'll see what I can do... When I get the time I'll try to
use your library in my project so you'll have another
real-world test user application available (Windows/MS
Visual Studio .NET 2003, and will be ported over to
*nix/gcc some time next year - so if the library is portable
its a major bonus as otherwise I'd have to rewrite my own).
Many thanks for all the effort you put in this so far. Certainly
looks promising.
Best regards,
Jurko Gospodnetic
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk