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

Subject: Re: [Boost-users] Boost::Serialization and MFC Doc/View architecture
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-07-03 14:19:53

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.

I've often  found the ms implemention often "good enough".  This is 
especially true for those older aps which don't using STL.  If they use the 
MS CArray, etc.  It's easier to use the ms serialization since it's already 
done for these data structures.  Many applications I do for customers are 
much simpler than other stuff I do and there's a strong bias to not add 
another (large) library so future programmers don't have to deal with a new 
thing to learn.

On the other hand, many times the MFC serialization just can't deal with it. 
This often happens when I use the CDocument as a "holder" for the "real" 
data which is more elaborate and exploits all the modern useful machinery 
like that boost and STL have: variants, stl collections, ranges, 
signals/slots, etc. etc.  This is the way I minimize my work - using MFC for 
the GUI, COM interfacing and all the other MS/Windows dependent stuff and a 
member of CDocument for all the heavy lifting.  I'm very much into 
minimizing effort, time and tedium.  Also my customers have very high 
expectations about what an application should do (everything) and low 
expectations about what it should cost (nothing since programming is "fun").

Sorry I wandered off topic.

So, my ap looks like

// CMy document
// standard MFC implementation for open, new, etc, etc, ....
// uses updateallviews and all the standard stuff

CMyDocument : public CDocument {
    // MFC serialize
    void
    Serialize(CArchive &ar){
        // now bridge to boost
        if(m_saving){
            ostream os = ar.... ; // I forget how I do this - I might even 
make a new output stream
            boost::text_oarchive oa(os)[
            oa << m_d;
        }
        else{
            ...
        }
    }
private:
    app_data m_d;
};

I don't know if that helps, but there it is.  It's mainly motivated by the 
fact that when I try to overload Open, New, I get all sorts of side-effects 
in MFC that I have to analize and track down.

Robert Ramey