Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk