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.