Re: [boost] [interprocess, aka shmem] Some proposals for open issues from the review

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-28 11:50:20

> This may be yet another half-backed idea, but, how different is the
> existing "primitive" shared_memory class from a basic_named_shared_object
> instantiation over a "null" memory algorithm, i.e. a memory algorithm
> that doesn't actually provide any allocation support? Could they be
> made to be the same if they aren't presently? That might permit the
> elimination of a level, which might then make naming easier.

Well, currently there is a possibility of a null index type, not a null 
algorithm. But even if that can be compatible we have several problems:

The real space the user can overwrite is dependent on the "null" size of 
the memory algorithm and the null index. The compilation of all that 
structure for a user that just want to create a shared memory segment 
would be an overkill.

I think that a simple shared_memory primitive (that just creates a 
segment and maps it) is useful because we have other operating system 
primitives (mapped file, mutex, semaphore).

> Some more alternatives in the naming scheme race:
> 
> - xxx_with_allocation, i.e. shared_memory_with_allocation, heap_with_allocation
> 
> - managed_xxx, i.e. managed_shared_memory, managed_heap

I don't have any problem with these proposals. But "managed" seems to be 
too overused to some users.

> Both of these are attempting to get across the idea that the differentiator
> between them and the underlying primitive shared_memory, heap memory, ... is
> that these higher level constructs provide support for managing allocation
> from the raw block of memory.

Yes, but it also allows anonymous object construction, named object 
construction and other features. I like "managed_shared_memory" because 
is shorter than other alternatives and compatible with the 
"segment_manager" concept. Any "managed_xxx" enemy out there?

Ion