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.