Re: [Boost-users] Boost::Serialization and MFC Doc/View architecture

Subject: Re: [Boost-users] Boost::Serialization and MFC Doc/View architecture
From: Colin Caprani (cc.caprani_at_[hidden])
Date: 2011-07-04 04:36:47

On Sun, Jul 3, 2011 at 7:19 PM, Robert Ramey <ramey_at_[hidden]> 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