[Boost-users] [Serialization] Issues with C++/CX in MSVC 11

Subject: [Boost-users] [Serialization] Issues with C++/CX in MSVC 11
From: Brent Lewis (brent_at_[hidden])
Date: 2012-05-02 19:09:23

In porting a project from iOS to Windows 8, I'm continuing to use Boost
1.49 to save the state of the program. I'm having what seems to be problems
with a compiler bug. I'm wondering if anyone has found a workaround?
Thought it's probably not necessary, I'll explain exactly what I'm seeing
in detail in case it's helpful.

If one creates a new Visual Studio project from the C++ Metro style
Direct3D application template, simply adding these lines to the main
function works just fine:

std::stringstream memStream(std::ios_base::binary | std::ios_base::in |
std::ios_base::out);
boost::archive::binary_oarchive oa(memStream);

However, when I add the rest of the project files (even if I don't
instantiate any of the classes - just adding the modules does it), the two
same lines in the main function crash. I eliminated all the code from the
modules that refer to serialization and archive classes, because I noticed
that there was a lot of static initialization of singletons of templated
archive classes. Even with minimal static initializers, still, the code
fails to run. Closest thing I can tell is that the compiler is not
correctly translating the this pointer when moving from a class's
initializers into a superclasse's constructor when multiple inheritance is
involved (and perhaps lots of templating is required too). To be specific,
in one specific run of the application (note that I've removed the template
parameters for brevity):

Inside binary_oarchive_impl ctor, the this pointer is: 0x0091fcb8
moving into its superclass constructor, basic_binary_oprimitive, the this
pointer is: 0x0091fcc1

That would suggest that the superclass is 9 bytes into the derived class,
however:

back inside the binary_oarchive_impl ctor, using the debugger:
(boost::archive::basic_binary_oprimitive*)this : 0x0091fcc4
offsetof(basic_binary_oprimitive, m_sb) = 0 (offsets retrieved by
inspecting/altering memory, since you can't get the offset of a reference
type)
offsetof(binary_oarchive_impl, m_sb) = 12

Which clearly indicates that the superclass is 12 bytes into the derived
class.

In the superclass, it initializes m_sb - which is a reference to the stream
buffer the archive writes to. Stepping back out of the superclass
constructor, back into the derived class constructor, m_sb points to the
wrong memory, of course. Has anyone else experience this with C++/CX? Is
there an existing bug report? We've got a Microsoft contact that's helping
us iron out issues. Does anyone know a concise repro that'll help MS solve
this problem faster? Thanks for any information.