Prev: Tracing a memory access error without using the debugger.
Next: serialize args correction
From: Goran on 19 May 2010 06:30
On May 19, 9:25 am, Goran <goran.pu...(a)gmail.com> wrote:
> Yeah, that's not.

Whoops! That should have been "that's not GOOD".

Goran.
From: RB on 19 May 2010 10:53
Again thanks Goran for all the extremely detailed information.
I have saved it and will examine it thoroughly included trying it
in a separate project to get all of what you are explaining.

Prior to reading this current reply from you I have been doing
some stepping thru code called outside of "my code" to try and get
a better picture of what was going on. And I found the following:

Keep in mind your recent post will also shed light on this but it
will take me awhile to decipher thru all you wrote. Additionally this
is just merely communciating, if the below is redundant to you
(or wrong ascertations on my part) then disregard it. I don't expect you
to reply to this since you have given me plenty that I have not yet had
a chance (but will ) digest.

----the following is within MyDocClass::Serialize function

CDocument::Serialize(ar); //Docs say to call base class func but I think this is
// for a generic CObject derivation not CDocument derivation, because if
// you step into this it calls the CObject base and it simply goes thru this do
// nothing code and returns
// _AFX_INLINE void CObject::Serialize(CArchive&)
// { /* CObject does not serialize anything by default */ }

pExpMap1 = &ExpMap1; //used for this trial

// ExpMap1.Serialize(ar); // For embedded objects that can call without the
// CObject << >> operators, the nMode for write or read has
// already been set when code arrives here, so you can just
// call it in one statement outside of the ar.IsStoring else
// loading brackets ( for known types with serialize functions)
// pExpMap1->Serialize(ar);

// prior to this MyDocClass::Serialize being called I see,
// stepping thru CDocument::OnSaveDocument (in DOCCORE.CPP) reveals a
// creation of an object instance "saveArchive" (the ar here) calling the CArchive class
// constructor in ARCCORE.CPP, this initializes many items in CArchive obviously
// used by CDocument and/or it's derived classes. It is here that nMode gets
// transferred from the UINT in the constructor arg to the BOOL m_nMode that is
// used by IsStoring()

if (ar.IsStoring()) // The IsStoring is calling merely to check m_nMode to
// advise which direction << >> operator.
{
ar << pExpMap1; // This stores CMap object to file
}
else
{
ar >> pExpMap1; //This does read it back
CString RetBuffx;
ExpMap1.Lookup(_T("a"), RetBuffx); // verifying correct value in read map.
}
} //end of MyDocClass::Serialize func

Also at a different time when stepping thru a call to
ExpMap1.Serialize(ar); // commented out in code above

I see inside this CMapStringToString::Serialize call the it does call it's base class

CObject::Serialize(ar)
// but it also gets the same generic do nothing code.
_AFX_INLINE void CObject::Serialize(CArchive&)
// { /* CObject does not serialize anything by default */ }


From: Goran on 20 May 2010 02:47
On May 19, 4:53 pm, "RB" <NoMail(a)NoSpam> wrote:
> Again thanks Goran for all the extremely detailed information.
> I have saved it and will examine it thoroughly included trying it
> in a separate project to get all of what you are explaining.
>
> Prior to reading this current reply from you I have been doing
> some stepping thru code called outside of  "my code" to try and get
> a better picture of what was going on. And I found the following:
>
> Keep in mind your recent post will also shed light on this but it
> will take me awhile to decipher thru all you wrote.  Additionally this
> is just merely communciating, if the below is redundant to you
> (or wrong ascertations on my part) then disregard it. I don't expect you
> to reply to this since you have given me plenty that I have not yet had
> a chance (but will ) digest.
>
> ----the following is within MyDocClass::Serialize function
>
> CDocument::Serialize(ar);    //Docs say to call base class func but I think this is
>       // for a generic CObject derivation not CDocument derivation, because if
>       // you step into this it calls the CObject base and it simply goes thru this do
>       // nothing code and returns
>       //                          _AFX_INLINE void CObject::Serialize(CArchive&)
>       //                          { /* CObject does not serialize anything by default */ }

Yes, and yet, as you found out, MFC code itself consistently calls
base class's Serialize, and that, without calling
SerializeClass(base). So are they not listening to their own advice?
Well, often they don't, but I think that's not the case here. I think
the reason why they don't SerializeClass(base) is this: quite often,
when user code serializes MFC containers, it simply does

m_MFCContainer.Serialize(ar);

And that works. So if MFC ever tries to change serialization of the
smallest thing in MFC, I bet you that there will be "broken
serialization!" cries up to high heavens. So CObject::Serialize will,
as far as load/store from the archive is concerned, stay empty
forever. It might do something else, not related to "on-disk" state
(e.g. add m_bLoadedFromFile flag). So what we, the users, should do,
is:

* when base class is MFC class, call
__super::Serialize.

* when base class is something of our own, call
SerializeClass(base);
__super::Serialize

* eventually, when we are certain that base class will never-ever-ever
change the schema, we can skip SerializeClass (not recommended, though
- us people are bad at telling future).

( This is all speculation and guessing on my part. Hopefully educated
enough, though, and it works for me, from MFC versions 4 to 9 ;-) )

Goran.
From: RB on 21 May 2010 15:07
Goran,
I had to work late last night and did not get back to you.
But I wanted to let you know that I did go over your class
serialize logistics and further I created a total separate project
and first copied every one of the macros to it and set my compiler
opts to /P /C and expanded every one them to fully get the
gest of what was happening. I ended up expanding more than
just the DECLARE...... and IMPLEMENT..... etc, I went all the
back to the RUNTIME_CLASS. And in the process I had
to pull out my old C++ book since I had forgotten about the
logistics of "static" inside a class. I now not only understand the
serialize better but I can see more of how the whole framework
ties together now. When I first looked at the Serialize function
I thought man that looks to easy to be true. And in fairness to
the designers, it was possible for a foo bar like me to actually
pass a CMap type to it and write and read it back from a file.
But now I see more of what really is going on in the process
working together with Serialize to make it what it should be.
Thanks again for all you input.


First  |  Prev  | 
Pages: 1 2
Prev: Tracing a memory access error without using the debugger.
Next: serialize args correction