Re: Question on use of "placement" new
On 17 mai, 18:15, l...@grame.fr wrote:
We have a class whose objects are to be allocated in shared memory. To
do that a ShmManager base class is defined so that operator new and
delete are redefined to allocate segments in shared memory. A typical
class "Foo" then inherit from ShmManager to have get this behaviour.
class ShmManager {
void* operator new(size_t size);
void operator delete(void* p, size_t size);
};
class Foo : public ShmManager
{
int fData1;
Barr fData2[16];
};
In the previous Foo example, the size of fData2 array is known
at compilation time, but we need to make this size "dynamic",
but keeping the object memory layout "flat".
Formally, it can't be done. Practically, see below. (I'm
assuming the Barr is a POD type. Otherwise, you'll run into any
number of problems.)
We are using the "placement" new syntax doing:
class Foo1 : public ShmManager
{
int fData1;
Barr fData2[]; // will be extented using "placement" new
};
ShmManager* ptr = ShmManager::operator new(sizeof(Foo1) + num *
sizeof(Barr));
Foo1* = new(ptr) Foo1();
That's legal C99, but not legal C++. In C++, it would cause
some additional problems (e.g. if you inherit from ShmManager).
To date, no one has done the work necessary to solve them, so it
probably won't be adopted into C.
The way I've worked around this in the (distant) past is to
define something like:
class Foo : public ShmManager
{
int fData1 ;
Barr* fData2() { return this + 1 ; }
public:
void* operator new( size_t n, size_t elementCount )
{
return ShmManager::operator new(
n + elementCount * sizeof( Barr ) ) ;
}
} ;
Note, however, that this may create problems with alignment.
In my case, Barr was in fact char, so the problem didn't
occur. If Barr is something more complicated, you'll have to
take additional steps to ensure that sizeof( Foo ) is a multiple
of the alignment needed for Barr.
Note that this requires the client code to use a somewhat
special syntax:
new ( n ) Foo ;
and that it only really works if Barr is a POD (but my
experience is that it's best to stick with POD's in shared
memory anyway).
So that Foo1 object nows gets a dynamic "num" number of
elements. This seems to work, but is this safe to do that?
It's not legal to specify an empty array specifier here, and if
you specify [1], and extend it, you have undefined behavior when
you attempt to access anything but the first element.
Are we obliged to put the fData2 fied as the *last* element in
the Foo1?
Yes. Otherwise, how would the compiler (not knowing n) know how
to find the other elements.
Is there any better/ safer manner to implement the same
pattern?
Even in shared memory, I'd keep variable length arrays separate.
Perhaps using some sort of smart pointer which only stores the
offset from the beginning of shared memory, and uses a global
variable (in the non-shared memory of each process) to calculate
the real address.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34