Click here to Skip to main content
14,774,519 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hi all,

I have a problem deserializing a file created with a VS2010 C++ program using a more-developed VS2015 version of the same program.

Some of the classes have been moved into DLLs, and I have changed the DECLARE_SERIAL and IMPLEMENT_SERIAL macros appropriately. Almost all old files load perfectly, deserializing classes moved into the DLL without issue.

The program structure is in essence this, with each class passing the deserialization up to its base class:

DLL contains:

CBaseDLL : public CObject {...};

CDerivedDLL1 : public CBaseDLL {...};

CDerivedDLL2 : public CDerivedDLL1 {...};


EXE contains:

CDerivedExe1 : public CBaseDLL 
{
    ....;
    CDerivedDLL2 *m_d2;

    void Serialize(CArchive &ar) {
        CBaseDLL::Serialize(ar);
        ar >> ....;
        ar >> m_d2;
    }
}

CDerivedExe2 : public CDerivedExe1
{
    ....;

    void Serialize(CArchive &ar) {
        CDerivedExe1::Serialize(ar);
        ar >> ....;
    }
}

CDocExe::Serialize()
{
	for (int i=0; i<3; ++i)
	{
		CDerivedExe2 *de2;
		ar >> de2;
	}
}


The odd thing is that there are three CDerivedExe objects in the file. The first one loads correctly. The second one fails.

What I have tried:

I have stepped right into the MFC loading code and the problem is in CArchive::ReadClass() (line 493 of arcobj.cpp), where m_pLoadArray returns that the class it is trying to load is of type CDerivedDLL2 instead of CDerivedExe2. I am assuming that somewhere the deserialization is getting confused about whether it's looking up a DLL class or an EXE class, but I can't see why it is working once and then failing.

Any suggestions gratefully received!
Posted
Updated 5-Dec-16 0:12am
Comments
hairy_hats 29-Nov-16 11:30am
   
The mystery deepens. I've moved the classes back into the EXE and the problem persists: the first object to be deserialized is fine, but the second is mis-interpreted by the schema lookup code.

You must override the >> operator to fix this issue. If stepping with the debugger into the >> operator you should see it.

IMHO: it isnt a good idea or clear design to overwrite classes from a dll.
   
Comments
hairy_hats 29-Nov-16 6:12am
   
Please can you explain further why I need to override the >> operator when the first object loads correctly using the >> operator? Thanks!

Also, doesn't CodeProject contain many classes which derive from MFC classes in DLLs?!
An ancient patch wasn't allowing the Class map in the CArchive deserialization code to be built up correctly once the classes were moved to the DLL. All working now.
   

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900