On Sun, Jul 3, 2011 at 7:19 PM, Robert Ramey <ramey@rrsd.com> 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