C / C++ / MFC

waldermort wrote:

If I do this in the dll I would need to include all the source files for the second class.

waldermort wrote:

I get unresolved external symbols for the three functions the dll uses (located in the main exe).

waldermort wrote:

In my origional code, I pass the class a pointer to another class (simply to control a progress bar on the main window).

waldermort wrote:

If I do this in the dll I would need to include all the source files for the second class.

DavidCrow wrote:

Bad design.

waldermort wrote:

I wouldn't call it a bad design when it isn't yet complete.

toxcct wrote:

the fact that app v2.0 doesn't read files of v1.0 is normal behavior (it is not supposed to recognize the version of the serialized object).

Zac Howland wrote:

What is the purpose in having a non-backwards-compatibly

Zac Howland wrote:

Being Lazy = More work down the road

MyClassOld.h :
 
class CMyClassOld {
    //schema v1.0
  private:
    std::vector<CFoo> m_vecFooList;
    std::vector<CFoo2> m_vecFoo2List;
 
    //...
};

MyClass.h :
 
class CMyClass {
    //schema v2.0
  private:
    std::vector<CFoo> m_vecFooList;
    //m_vecFoo2List not existing anymore
 
    //...
};

#include "MyClassOld.h"
#include "MyClass.h"
 
CMyClassOld o1;
CMyClass o2;
 
//reads a CMyClassOld serialized object into o1
 
//converts it to a CMyClass object (into o2)
 
//Serializes o2

toxcct wrote:

what if the new business schema doesn't know its previous versions design ?

Ravi Bhavnani wrote:

since you can't do a silent upgrade (or a separate migration) without full knowledge of the old and new schemas