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