On Sun, Jul 3, 2011 at 7:19 PM, Robert Ramey wrote:

Colin Caprani wrote:

...

I hope you don't mind, but I've a bit more information on this:

I'm personally very familiar with MFC and it's implemenation of serialization. In fact, it was this system which inspired me to write the serialization library in the first case. So here are a couple of observations.

Robert, Firstly thank you for replying. Secondly, a bigger thanks for the library! Since I am not an expert/professional programmer, I wasn't sure that I wasn't missing something obvious. Once I read your answer and accepted that for the CMyDoc class itself the serialize(Archive& ar, const unsigned int version) function wasn't a runner I implemented separate boost_save and boost_load functions. However, contrary to what you mentioned, I had to overload the OnOpenDocument and OnSaveDocument, for example: BOOL CMyDoc::OnOpenDocument(LPCTSTR lpszPathName) { clear(); // Call base class function with empty local Serialize function // to check file exists etc if (!CDocument::OnOpenDocument(lpszPathName)) return FALSE; std::string file( lpszPathName ); boost_load(file); return TRUE; } This is necessary since the MFC CArchive owns the file until the MFC Serialize function exits, disallowing boost::serialization to access the file. Even calling ar.Abort() in the Serialize functions doesn't work because the CDocument base class assumes the ar exists on returning to the base class Serialize function. I now have one small(ish) problem: I get a memory exception when I try to delete a pointer to an object created from a load operation in the clear() function. It fails at: _ASSERTE(pHead->nBlockUse == nBlockUse); I think it's because the serialization library allocates on a different heap to the local one. This this sound right? I know it's not great practice but I can probably live with this leak until I implement shared_ptr which should eliminate it - am I right about that?! Thanks for all the help, Colin

On Mon, Jul 4, 2011 at 4:55 PM, Robert Ramey wrote:

My personal experience is that ignoring this will lead to grief down the road. I don't know what your load function does so I can't comment in particular case.

You're right! I've replicated the problem in a skeletal MFC application. All default options used on creation in VS2010, SDI application, unicode off, shared DLL. I attach the following in case it helps: 1. MyTypes & MyType class definitions file 2. CBoostSerializationTestDoc files 3. BoostSerialize.h boost includes MyTypes is just a collector of MyType, but is stored as an owned pointer in the Doc class. There are two problems that occur: 1. The assertion failure mentioned previously: To replicate this, run the program save a file (first.bst) and save another file (second.bst). Open first.bst, then open second.bst to get failure. This problem is fixed by commenting out the CObject inheretence on the MyType and MyTypes classes (the inheretence is legacy from MFC serialization used in the original app). 2. A memory leak on exit when the Problem #1 assertion is fixed.

From inspection of debug output window. Many 8 bytes, which I suspect as m_Val's of MyType.

I suspect that I may be making a basic error, perhaps not though, and that's why I'm following up. Thanks for any help you can offer, Colin