Re: Pimpl idiom without dynamic memory allocation

I noticed above that there was a suggestion using:
aligned_storage<..>. From my understanding this class does not exit in
the current C++ standard but is being considered for C++0x ? Also is
there any runtime overhead caused by the overloaded operator -> in
that implementation. If not then it it probably a much better
implementation than what i started working on last night...

Following on from this thread, i have been working on an
implementation of the PIMPL pattern that i think will work by
allocating correctly on the stack. Would others be able to take a look
at it and let me know if this will fail? I have tested it with GCC on
linux + MinGW and MSVC. The point of this is to try and remove the
small runtime penalty from the pointer dereference with the typical
PImpl implementation.

I have created a number of macros that will let me achieve this simply
using a single class definition which using macro trickery changes the
internals of the class between the header presented to the public and
the cpp file that implements the internals. But for demonstration i
will give the code for a header and cpp file as simple as possible
with no macros. I have also removed a number of compile time checks
that are in the macro version.

The basic concept is that the public implementation looks just like a
lump of aligned memory (char array in this case) and defines calls to
constructors/destructor and assignment operator which must not be
implicit or inline. These are used to "initialise"/"destroy" that lump
of memory. In the private implementation this lump of aligned memory
actually looks like a class with a little bit left over. So the class
itself looks different based on where you are looking at it from. I
dont like this, but can not see a way of avoiding it.

The macro implementation also uses different methods to align the
array for different compilers. Following is a list of possible issues
i can see with this:

* Requires compiler specific implementation for variable alignment
(There is a generic one that attempts to place a union of various data
types just before the char array in order to try and align it
correctly. This is wasteful of memory but i "think" will work for
compilers i haven;t handled with variable alignment specifications
like GCC below)

* If the compiler produces padding between the Implementation instance
in the cpp file and the char array that follows, then the size of the
StackPImpl in the cpp file will differ from its size in the public
causing all sorts of problems.

   - I dont know if this will ever occur. It will only occur if the
sizeof(StackPImpl_IMPL) is such that the alignment of a char array
will require padding before it.
   - Could be solved again by defining the char array in the private
implementation as not being aligned

* Will have size issues on systems where sizeof(char) != 1
   - May fix by defining size of array as array[SIZE / sizeof(char) +
1]

Would people be able to take a look at this and let me know if they
can for-see any issues?

Thanks,
Brendon.

--- header ---
#define SIZE 8
class StackPImpl
{
public:
   StackPImpl();
   ~StackPImpl();
   StackPImpl(const StackPImpl& right);
   StackPImpl& operator=(const StackPImpl& right);
   void Public();

   unsigned char pimpl_data[SIZE] __attribute__((aligned));
};

--- cpp implementation ---
class StackPImpl_IMPL
{
public:
   int data;
};

#define SIZE 8
class StackPImpl
{
public:
   StackPImpl();
   ~StackPImpl();
   void Public();

   StackPImpl_IMPL pimpl __attribute__((aligned));
   unsigned char pimpl_data[SIZE - sizeof(StackPImpl_IMPL)];
};

StackPImpl::StackPImpl()
{
}

StackPImpl::~StackPImpl()
{
}

// @@@Brendon Could not be bothered implementing operator= and copy
for this eg

void StackPImpl::Public()
{
   pimpl.data++;
}