🚀 go-pugleaf

Ed Swartz <eswartz@antispam.metrowerks.com> wrote:

> Well, even given the specific rules, your problem is deeper than the member
> layout.  CFM and Mach-O use completely different ABIs, so the layout of C++
> objects is unlikely to correspond between the two (the vtable pointer, for
> instance, is in different places).  CFM is based off a 16-bit 68K
> architecture, while Mach-O is based off a 32-bit PPC architecture, so there
> are inherent unconfigurable differences in the ways the invisible parts of
> the classes are aligned.

Our classes do have virtual functions (destructors, mostly), but we are
careful to call them only from the Mach-O side.  This is working fine.

We are not using any other RTTI features on these objects.

So far it seems that the alignment problem with derived classes is the
only problem in practice.  We had this only for very few classes, and
were able to fix the problems by manually padding the classes.  The
problem with this approach is that it is hard to test.  (We are
considering putting

  BOOST_STATIC_ASSERT((sizeof(MyClass) % 8) == 0);

after the declaration of each of the shared classes, but this is still
easy to forget for new classes.)

> I would recommend using C structs instead.

This is not an option.  We have a very large code base that is already
using these C++ classes, there's no way we can rewrite it all, using
different data structures.

> Beyond that, #pragma pack(1) ... pack(8) would be best for assuring the
> struct layouts are the same between the two compilers.

The C compiler manual doesn't list this as supported by the Mac
compilers.  #pragma pack(1) does work though, and it even achieves the
desired effect of getting the same alignment on both Mach-O and CFM;
however, it is completely useless, because it will merrily put ints and
doubles on odd addresses.

To sum it up: it seems that manually padding our classes to multiples of
8 bytes is our only option, right?


-- 
Stefan Haller
Berlin, Germany
http://home.snafu.de/stk/