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

From: Kim Barrett (kab_at_[hidden])
Date: 2006-02-27 16:08:46

At 6:37 PM +0100 2/27/06, =?UTF-8?B?SW9uIEdhenRhw7FhZ2E=?= wrote:
>  > I don't like "services" much, especially the plural form. The object
>>  of this class would be number of services or a single service? And
>>  after all, this class is just more convenient and high-level interface
>>  to lower-level interfaces, so I don't think "services" is a good name.
>>  Maybe just leave "named_" prefix, but cut out the "_object" which
>>  doesn't add much information. Then you will have
>>  named_shared_memory
>>  named_mapped_file
>>  named_heap_memory
>>  etc.
>
>Some users have suggested more descriptive names:
>
>objects_in_shared_memory
>objects_in_mapped_file
>objects_in_heap_memory
>objects_in_user_memory
>
>A bit long but I think the class expresses very clearly its use. We can
>make it shorter with "objects_in_shmem"/"objects_in_mfile", but is not
>very pronounceable. This name issue is harder than the review! Comments?

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.

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

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.