DocClass Implement Serial
in [MFC]
|
Prev: https://accountservices.msn.com/EmailPage.srf?emailid=5d4c1ef525bf
Next: Reminder - Microsoft Responds to the Evolution of Community
From: RB on 20 Jun 2010 10:51 Well I have done a bit more study and experimenting and I have 3 questions. Appreciate input from everyone as usual and hopefully Goran will also reply since he has helped me the most on serialization and from going back and rereading the context of his replies (after I studying and experimenting enough to even understand them) I can tell the he has a firm grasp on what is going on in MFC's serialization process. , My first question is, I can not help but wonder why MFC does not generate the Doc class (derived from CDocument) with the Serial macros as opposed to the Dyncreate. Like at first I was thinking of creating a whole other class derived from CObject with implement serial just to hold members I wanted a schema to, but then Goran gave an example of the mfc schema with creating the DocClass with SERIAL and after he showed this to me I began to wonder why MFC did not generate it that way ? Maybe because of ...... ( Goran did not recommend it since this ties serialization with your document class name, so you could have trouble changing it using of serializeClass or operator<</>> and might be a problem if a major overhaul of serialization occurs) 2 other questions below, denoted with ************ one simple mfc comment queston and another question on 2nd set of code at bottom. -------Implementing DocClass Serial instead of Dyncreate------ class CFileHandlingDoc : public CDocument { // RB question what exactly does this MFC generated comment mean ? // | | | ************ protected: // create from serialization only CFileHandlingDoc(); // DECLARE_DYNCREATE(CFileHandlingDoc) // RB doc creation with serial instead DECLARE_SERIAL(CFileHandlingDoc) .......... .......... } // CFileHandlingDoc implementations // IMPLEMENT_DYNCREATE(CFileHandlingDoc, CDocument) // RB creating doc with serial instead IMPLEMENT_SERIAL(CFileHandlingDoc, CDocument, 0) // And in my DocClass serialize function void CFileHandlingDoc::Serialize(CArchive& ar) { if (ar.IsStoring()) { ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); ar << VerData.Ver << VerData.CpyRt << VerData.Corp; ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); ExpMap1.Serialize(ar); } else { ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp; ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); ExpMap1.Serialize(ar); } } // The above compiles and works on writes and reads doc class // CRuntime Data with no problems ++++++++appreciate comments on below +++++++++++++ So then I am later reading in MFC Under the Hood by Laura Draxler on page 255 on the use of the SERIAL macros for user classes derived from CObject, she says: "It may seem inconsistent to you at first that document class does not need the SERIAL macros, and it uses the DYNCREATE macros instead, but the framework provides this support automatically for the document class." ---- And I am thinking yes it does seem that document class would use SERIAL. But I obviously have misunderstood the the context of her saying the framework provides serial for the doc class, since when I expanded the dyncreate macro and inserted my schema of 0 (instead of the default FFFF for dyncreate) the SerializeClass call failed on a read in. So she must be referring to another aspect of this. (see code expansion below) /////////////////////////////////////////////////// // CFileHandlingDoc // Seeing if framework provides serial under implement dyncreate ? // IMPLEMENT_DYNCREATE(CFileHandlingDoc, CDocument) // Expanded CObject* __stdcall CFileHandlingDoc::CreateObject() { return new CFileHandlingDoc; } const CRuntimeClass CFileHandlingDoc::classCFileHandlingDoc = { "CFileHandlingDoc", sizeof(class CFileHandlingDoc), 0x0000, // !RB replaced the 0xFFFF,! **************** CFileHandlingDoc::CreateObject, ((CRuntimeClass*)(&CDocument::classCDocument)), 0 }; CRuntimeClass* CFileHandlingDoc::GetRuntimeClass() const { return ((CRuntimeClass*)(&CFileHandlingDoc::classCFileHandlingDoc)); } // End Implement_Dyncreate expansion
From: Goran on 20 Jun 2010 13:02 On Jun 20, 4:51 pm, "RB" <NoMail(a)NoSpam> wrote: > Well I have done a bit more study and experimenting and I have 3 questions. Ok, you are going ahead of you now. You are not supposed to know the answer to all these questions so fast, you need 3 years MFC serialization experience first, minimum! ;-) > Appreciate input from everyone as usual and hopefully Goran will also reply > since he has helped me the most on serialization and from going back and > rereading the context of his replies (after I studying and experimenting enough > to even understand them) I can tell the he has a firm grasp on what is going on > in MFC's serialization process. , > My first question is, I can not help but wonder why MFC does not > generate the Doc class (derived from CDocument) with the Serial macros > as opposed to the Dyncreate. I guess simply because MFC does need _DYNCREATE (to create the document at runtime, from a template), but does not need _SERIAL, because MFC simply calls Serialize(ar); on the document class. Clearly, to simply call Serialize on an object, you don't need any of these macros. Now, remember, _SERIAL gives serialization operators >> and <<, and schema number. Since every serialization code I've seen so far has "global" document version, and some "magic" file type marker (your own does it), I proposed the use of DECLARE_SERIAL and SerializeClass simply because that will give you both, without reaching out for a custom solution. SerializeClass will store class name in the serialization stream (that's your "magic" file type marker), and will also store the version (that's... well, version). In all honesty: I came up with this idea of my own and I don't know if someone else does that. But I see no flaw in it. BTW, IIRC ;-)... If there's an error in the file (e.g. it's really something else, not your file), SerializeClass throws an exception with CArchiveException::badClass. That gets nicely reported in document's ReportStoreLoadException. > Like at first I was thinking of creating a whole > other class derived from CObject with implement serial just to hold members > I wanted a schema to, but then Goran gave an example of the mfc schema > with creating the DocClass with SERIAL and after he showed this to me I began > to wonder why MFC did not generate it that way ? Maybe because of ...... > ( Goran did not recommend it since this ties serialization with your document > class name, so you could have trouble changing it using of serializeClass or > operator<</>> and might be a problem if a major overhaul of serialization occurs) > > 2 other questions below, denoted with ************ > one simple mfc comment queston and > another question on 2nd set of code at bottom. > -------Implementing DocClass Serial instead of Dyncreate------ > > class CFileHandlingDoc : public CDocument > { > // RB question what exactly does this MFC generated comment mean ? > // | | | ************ > protected: // create from serialization only > CFileHandlingDoc(); Stupid and untrue wizard comments. ;-) I guess it wants to say: ctor is protected because this will be created from serialization only. But document will be created at runtime when creating a new document, too, so it's untrue that it's from serialization only. Only when document is open, "dynamic creation" AND seralization happen. > // DECLARE_DYNCREATE(CFileHandlingDoc) > // RB doc creation with serial instead > DECLARE_SERIAL(CFileHandlingDoc) > .......... > .......... > > } > > // CFileHandlingDoc implementations > > // IMPLEMENT_DYNCREATE(CFileHandlingDoc, CDocument) > // RB creating doc with serial instead > > IMPLEMENT_SERIAL(CFileHandlingDoc, CDocument, 0) Wow, wow, not like that! You need SERIALIZABLE_SCHEMA in there. I always start with SERIALIZABLE_SCHEMA|1, but I guess you can start with 0 as well. > > // And in my DocClass serialize function > void CFileHandlingDoc::Serialize(CArchive& ar) > { > if (ar.IsStoring()) > { > ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); No, that goes in front of the "if". Otherwise, you're calling it twice for no reason. See below, you do it already. > ar << VerData.Ver << VerData.CpyRt << VerData.Corp; > ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); > ExpMap1.Serialize(ar); > } > else > { > ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); > ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp; > ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); > ExpMap1.Serialize(ar); > } } > > // The above compiles and works on writes and reads doc class > // CRuntime Data with no problems > > ++++++++appreciate comments on below +++++++++++++ > So then I am later reading in MFC Under the Hood by > Laura Draxler on page 255 on the use of the SERIAL > macros for user classes derived from CObject, she says: > "It may seem inconsistent to you at first that document > class does not need the SERIAL macros, and it uses the > DYNCREATE macros instead, but the framework provides this > support automatically for the document class." I believe that this stems from a common misconception that you need XXX_SERIAL if you want to use serialization. Not necessarily. If all you want is to call Serialize, do it and forget XXX_SERIAL (in fact, you can often forget _DYNAMIC and _DYNCREATE, too). But schema changes get harder then ;-). As I explained before, MFC calls Serialize on the instance of the document class, but that's the end of it. It certainly does __not__ provide any additional support for document's serialization (logical, how can it know about stuff I want to save?). So if it's not calling SerializeClass, and it is not using << / >>, it does not need XXX_SERIAL, so why do it? I'd say that the explanation in the book is confusing at best. Goran.
From: Joseph M. Newcomer on 20 Jun 2010 18:01 See below... On Sun, 20 Jun 2010 10:51:39 -0400, "RB" <NoMail(a)NoSpam> wrote: > >Well I have done a bit more study and experimenting and I have 3 questions. >Appreciate input from everyone as usual and hopefully Goran will also reply >since he has helped me the most on serialization and from going back and >rereading the context of his replies (after I studying and experimenting enough >to even understand them) I can tell the he has a firm grasp on what is going on >in MFC's serialization process. , > My first question is, I can not help but wonder why MFC does not >generate the Doc class (derived from CDocument) with the Serial macros >as opposed to the Dyncreate. **** It does seem odd, but it also means that they are not assuming you require serialzation. I'd be in the other fix, having to constantly get rid of DECLARE/IMPLEMENT_SERIAL because I don't ever want to use the MFC serialization mechanism. It is often a coin-toss as to which choice is made. ***** > Like at first I was thinking of creating a whole >other class derived from CObject with implement serial just to hold members >I wanted a schema to, but then Goran gave an example of the mfc schema >with creating the DocClass with SERIAL and after he showed this to me I began >to wonder why MFC did not generate it that way ? Maybe because of ...... > ( Goran did not recommend it since this ties serialization with your document > class name, so you could have trouble changing it using of serializeClass or > operator<</>> and might be a problem if a major overhaul of serialization occurs) > >2 other questions below, denoted with ************ >one simple mfc comment queston and >another question on 2nd set of code at bottom. >-------Implementing DocClass Serial instead of Dyncreate------ > >class CFileHandlingDoc : public CDocument >{ > // RB question what exactly does this MFC generated comment mean ? > // | | | ************ >protected: // create from serialization only > CFileHandlingDoc(); > >// DECLARE_DYNCREATE(CFileHandlingDoc) >// RB doc creation with serial instead > DECLARE_SERIAL(CFileHandlingDoc) > .......... > .......... >} > >// CFileHandlingDoc implementations > >// IMPLEMENT_DYNCREATE(CFileHandlingDoc, CDocument) >// RB creating doc with serial instead > > IMPLEMENT_SERIAL(CFileHandlingDoc, CDocument, 0) > >// And in my DocClass serialize function >void CFileHandlingDoc::Serialize(CArchive& ar) >{ **** I have often felt this whole mechanism was designed by a totally clueless programmer. Probably the same twit that decided that we only needed UpdateData with a BOOL to indicate direction. I keep seeing this kind of horrid overloading of concepts in designs and wonder how it is that the same mistake gets repeated so often. In a sane worled, there would be SerializeIn(CArchive & ar) and SerializeOut(CArchive & ar). And the stupid IsStoring method would not have to exist. I think these are the same people who think that creating more files is evil. **** > if (ar.IsStoring()) > { > ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); > ar << VerData.Ver << VerData.CpyRt << VerData.Corp; > ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); > ExpMap1.Serialize(ar); > } > else > { > ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); > ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp; > ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); > ExpMap1.Serialize(ar); > } >} >// The above compiles and works on writes and reads doc class >// CRuntime Data with no problems > >++++++++appreciate comments on below +++++++++++++ >So then I am later reading in MFC Under the Hood by >Laura Draxler on page 255 on the use of the SERIAL >macros for user classes derived from CObject, she says: >"It may seem inconsistent to you at first that document >class does not need the SERIAL macros, and it uses the >DYNCREATE macros instead, but the framework provides this >support automatically for the document class." >---- >And I am thinking yes it does seem that document class >would use SERIAL. But I obviously have misunderstood >the the context of her saying the framework provides >serial for the doc class, since when I expanded the >dyncreate macro and inserted my schema of 0 (instead of >the default FFFF for dyncreate) the SerializeClass call >failed on a read in. So she must be referring to another >aspect of this. (see code expansion below) **** I have no idea. Serialize is so badly done I cannot imagine why I would ever want to use it. I knew about most of its problems in 1979, when we designed the LG system (think: XML done right), and I was apalled to find MFC had reinvented all the problems we knew were horrid problems decades before. All data should be tagged, self-identifying data. XML is a good representation for this. **** > >/////////////////////////////////////////////////// >// CFileHandlingDoc > >// Seeing if framework provides serial under implement dyncreate ? >// IMPLEMENT_DYNCREATE(CFileHandlingDoc, CDocument) >// Expanded > >CObject* __stdcall CFileHandlingDoc::CreateObject() > { > return new CFileHandlingDoc; > } > >const CRuntimeClass CFileHandlingDoc::classCFileHandlingDoc = > { "CFileHandlingDoc", sizeof(class CFileHandlingDoc), > 0x0000, // !RB replaced the 0xFFFF,! **************** **** Why? Just curious. **** > CFileHandlingDoc::CreateObject, > ((CRuntimeClass*)(&CDocument::classCDocument)), 0 > }; > >CRuntimeClass* CFileHandlingDoc::GetRuntimeClass() const > { > return ((CRuntimeClass*)(&CFileHandlingDoc::classCFileHandlingDoc)); > } >// End Implement_Dyncreate expansion Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: RB on 20 Jun 2010 19:25 > Goran wrote > I guess simply because MFC does need _DYNCREATE (to create the > document at runtime, from a template), but does not need _SERIAL, > because MFC simply calls Serialize(ar); on the document class. > Clearly, to simply call Serialize on an object, you don't need any of > these macros. RB replied Hey guy, thanks for replying. Yes I understand that the document doesn't necessarily "need" the Serial macro to write to file, but I couldn't understand why MFC would want to short the full capability of the schema in the doc. Or at least say why they did not. It just doesn't at first make sense from my limited view point, although see below for more. > Goran wrote > Now, remember, _SERIAL gives serialization operators >> and <<, and > schema number. Since every serialization code I've seen so far has > "global" document version, and some "magic" file type marker (your own > does it), I proposed the use of DECLARE_SERIAL and SerializeClass > simply because that will give you both, without reaching out for a > custom solution. SerializeClass will store class name in the > serialization stream (that's your "magic" file type marker), and will > also store the version (that's... well, version). RB replied Exactly and it seems to me that if all the help text points towards using the full power of serial in a CObject derived class why would the document derivative not be included since to me it is the base of the whole serialization process. Like if I have CMapStringToString's Runtime data and schema written to my file but I don't have my doc derivative's runtime data in the file unless I learn it from you on a news group, or my member data's schema unless I do what the help text says and put them in another CObject derived class with the full power of Serial macros. The whole thing just seems odd to me, unless for they were not wanting to tie the whole thing to the doc derivative's name as you previously pointed out, and if so why didn't they say so. See more on this lower down. > Goran wrote > In all honesty: I came up with this idea of my own and I don't know if > someone else does that. But I see no flaw in it. BTW, IIRC ;-)... If > there's an error in the file (e.g. it's really something else, not > your file), SerializeClass throws an exception with > CArchiveException::badClass. That gets nicely reported in document's > ReportStoreLoadException. RB replied Well actually about the same time you showed it to me I got out an old book I had bought used quite a while ago "MFC Programming by Alan Feuer" and I looked thru it and found the same idea (creating the doc derivative with the Serial macros ). But other than you and this one book, I have not seen it elsewhere searching on the net or other MFC books I have. >> RB previously wrote >> IMPLEMENT_SERIAL(CFileHandlingDoc, CDocument, 0) > Goran wrote >Wow, wow, not like that! You need SERIALIZABLE_SCHEMA in there. > I always start with SERIALIZABLE_SCHEMA|1, but I guess you can start > with 0 as well. RB replied Yes you showed me correct, I did the zero thing. Not much thought involved just figured I would start with zero since CMapStringToString does. Actually I have read about OR-ing the VERSIONABLE_SCHEMA define with the file schema, but I haven't yet gotten underneath the rhyme and reason of it. >> RB previously wrote >> if (ar.IsStoring()) >> { >> ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc)); > Goran wrote > No, that goes in front of the "if". Otherwise, you're calling it twice > for no reason. RB replied Well yes you are correct. I did this because I had wanted to keep the order of Class runtime writes in order before their pertinant data writes. Of course obviously I could just skip this on the first object being written, but on all the other's CmStS etc, I would have to put them in both if else loops to keep the runtime data right with the actual object data (unless it was heap item and I used the ptr operator methods which does the WriteClass and the data write both together). >> Goran previously wrote >>Notes: >>* this ties serialization with your document class name, so you will >>have trouble changing it RB replied, well if I understand correctly what you meant with that statement, THIS would to me be a conceivable reason MFC designers did not include the Serial macro on the doc derivative. Because if you ever changed the name of you doc derivative in a future version you would never be able to read an old file back (with serialize anyhow) into a new version with a different doc class name. So maybe they thought it better to aim the help texts at a separate CObject derivative for SERIAL creation. That way if you changed the name of your app (slightly or otherwise) then the AppWizard generations would not break the doc derivative class's name tie to the older versions. >> Goran previously wrote >> (That might be a problem when/if a major overhaul of serialization >> occurs). RB replied Not quite sure exactly what you meant by a major overhaul of serialization. I am assuming you mean if I change my Doc derivatives name ? I know all of this has helped me learn more about the whole MFC structure so that is a plus. But at this point I kinda feel like "not" serializing the schema and class runtime "name" data of my doc derivative. In fact I think I would feel more comfortable going back with the MFC dyncreate creation and just writing out my doc data members to file first before any CObject derivatives that follow like CmStS or any others. That way I could just use my own schema system that is not tied to the doc derivative's name. As always I have learned a great deal from your replies. For a person wanting to learn, the newsgroup setup and people like you, Joe, Giovanni and all the other guys are a priceless help. RB
From: RB on 20 Jun 2010 20:01
Hey Joe thanks for replying > It does seem odd, but it also means that they are not assuming you require serialzation. > I'd be in the other fix, having to constantly get rid of DECLARE/IMPLEMENT_SERIAL > because I don't ever want to use the MFC serialization mechanism. > **** Well actually that is a very conceivable reason for not creating serial, so that makes two reasons so far. Since as Goran had pointed out to me serial ties the doc derivative class's name to the serialize schema. So I surmise that in future apps that had a slightly different name and doc derivative class name would break the Runtime class data match for a read from a newer version. That makes sense as to why the help texts always seem to point to making a separate CObject derivative for SERIAL creations. The thing that got me is why they did not be more clear about it and say it ? > In a sane worled, there would be SerializeIn(CArchive & ar) and SerializeOut(CArchive & > ar). And the stupid IsStoring method would not have to exist. > I think these are the same people who think that creating more files is evil. > **** Well as far as the mfc serialize scheme goes I can see that putting the storing and loading loops together helps keep the same order of writes and reads in my face so it might be visually less error prone. But I guess you could do that in your method also so that doesn't hold much water. But actually now I feel like I will use the dyncreate method and devise my own schema method for doc derivative members that need stored and keep the mfc serialize runtime class method for CmStS or any CObject derivatives I may need to create Serial. At least for the time being. As I get more experience under my belt I may forgo all of this ( like you) and just write my own persistence functions. >>const CRuntimeClass CFileHandlingDoc::classCFileHandlingDoc = >> { "CFileHandlingDoc", sizeof(class CFileHandlingDoc), >> 0x0000, // !RB replaced the 0xFFFF,! **************** > **** > Why? Just curious. > **** Nothing except having read the Laura said the framework supported serialize in the doc class without creating with Serial, I wanted to see if I could insert my schema of zero into the expanded dyncreate macro and then write and read it back. And I found that it did not work, so she must have been referring to some other aspect of framework support. It did write ok, I could see it in the dump. But it failed to read it back I presume since it did not have all of the serial macro capability to compare the written Class runtime data. |