In porting a project from iOS to Windows 8, I&#39;m continuing to use Boost 1.49 to save the state of the program. I&#39;m having what seems to be problems with a compiler bug. I&#39;m wondering if anyone has found a workaround? Thought it&#39;s probably not necessary, I&#39;ll explain exactly what I&#39;m seeing in detail in case it&#39;s helpful.<div>
<br></div><div>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:</div><div><br></div><div><div>std::stringstream memStream(std::ios_base::binary | std::ios_base::in | std::ios_base::out);</div>
<div>boost::archive::binary_oarchive oa(memStream);</div></div><div><br></div><div>However, when I add the rest of the project files (even if I don&#39;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 <font face="&#39;courier new&#39;, monospace">this</font> pointer when moving from a class&#39;s initializers into a superclasse&#39;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&#39;ve removed the template parameters for brevity):</div>
<div><br></div><div>Inside binary_oarchive_impl ctor, the this pointer is: 0x0091fcb8</div><div>moving into its superclass constructor, basic_binary_oprimitive, the this pointer is: 0x0091fcc1</div><div><br></div><div>That would suggest that the superclass is 9 bytes into the derived class, however:</div>
<div><br></div><div>back inside the binary_oarchive_impl ctor, using the debugger: (boost::archive::basic_binary_oprimitive*)this : 0x0091fcc4</div><div>offsetof(basic_binary_oprimitive, m_sb) = 0 (offsets retrieved by inspecting/altering memory, since you can&#39;t get the offset of a reference type)</div>
<div>offsetof(binary_oarchive_impl, m_sb) = 12</div><div><div><br></div></div><div>Which clearly indicates that the superclass is 12 bytes into the derived class.</div><div><br></div><div>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&#39;ve got a Microsoft contact that&#39;s helping us iron out issues. Does anyone know a concise repro that&#39;ll help MS solve this problem faster? Thanks for any information.</div>