Hi again,
you have a compelling use case for a placement 'new' operator but there is no such operator provided by the Genode framework for good reasons:
- A placement new operator is very simple. Indeed, its only one line of code, which does not relate in any way with rest of the Genode framework. It is completely independent. If you like, you are free to implement one in a custom header file of your's and use it from several places.
- Having to use of a placement new operator is (and should be) rare. If it cannot be avoided, it is the best to provide it local to where it is used to document the reason of why it is needed in the particular case. If not used with caution, a placement new operator is easy to misuse (in particular if overloads exist - see below).
- You already found that our only "official" new operator takes an 'Allocator' as argument. This argument allows you to specify the memory pool from where to allocate. For the motivation, see the "heap partitioning concept" of Genode:
http://genode.org/documentation/architecture/framework#Heap_partitioning
Because the 'Allocator' interface is abstract, it further enables the use of customized allocation strategies by supplying different 'Allocator' arguments to different sub systems. This way, allocation strategies can be optimized (e.g., using slabs or a list-based implementation) without changing the code that uses 'new'.
If we provided a general placement new operator, this would overload our standard new operator, which could lead to really bad errors. For example, assume that your code included 'placement_new.h' but not 'allocator.h', and you try passing a real allocator interface as argument to 'new'. In this case, the placement new operator would be used w/o any compiler warning and the new object would corrupt the 'Allocator' object.
If you like to stick with the classes provided with the Genode framework, there is a clean way to solve your placement-new problem by introducing a new 'Allocator' implementation - quite similar to the 'Sliced_heap' allocator. But your special allocator would allow for only one allocation. A 'Single_allocator' object would hold the dataspace capability ('ds_cap'). When 'alloc' called and the 'ds_cap' is not already initialized, a dataspace is allocated and locally mapped. The local address is then returned. The destructor could automatically unmap and free the dataspace. This way, the lifetime of the dataspace gets implicitly taken care of. For allocating an instance of your 'Object', you will need a dedicated 'Single_allocator' instance (hosted outside the shared-memory of course), which you supply as argument for 'new'.
And worse, its implementation tries to effectively allocate the object’s
Honestly, I do not know why you are using the word 'worse'. Which part of our interfaces is unreasonable from your point of view?
Regards Norman