|
dear all,
i have solved my problem already, but with a way i don't like at all. but i couldn't find a working method in the time i had to do the job.
here is the topic :
i have a program (say v1.0) which serializes its objects into binary files.
but this program has grown up to v2.0, and the objects serialization scheme has changed.
both versions were working fine independantly. but the problem was starting when a version was trying to open an object which scheme was of the wrong version. 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).
the thing is that i had to make an external project for the migration.
in the project, i have the sources of the new objects linked as an additionnal source directory in the compiler settings, and the old sources are directly copied in the migration project directory.
but as the objects files/classes remained the same between the 2 version, the compiler complains about types redefinitions.
i had the idea of putting the sets of sources into different namespaces, but i didn't succeed in doing this.
the only solution i found to compile the migration tool was to rename all the types of the old version, ,and appending an "Old" to their name... bad, isn't it ? 
so, i'd like to know you advise for the best design you think of to solve such a problem.
thanks already for your answers.
ps : i'm leaving internet, so, don't worry if i don't answer immediately
|
|
|
|
|
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).
That is an odd requirement. Typically, backwards compatibility is a desirable feature, and something that is not backwards compatible is not desirable.
MFC provides the schema version when you are serializing objects. Typically, you just check the schema before you read the data and then use the correct version of the read operation (the write operation is always done with your most up-to-date version, so that doesn't matter).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
i know that Zac, but that's not the question...
|
|
|
|
|
I realize that. My response was suppose to be more of a question: What is the purpose in having a non-backwards-compatibly serialization scheme for these classes that are apparently designed for the same purpose?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: What is the purpose in having a non-backwards-compatibly
laziness maybe 
|
|
|
|
|
The thing is, if you fix that, you no longer have this problem to begin with. Being Lazy = More work down the road.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Being Lazy = More work down the road
lol, yes, i'm gonna tell this to the owner of the code...
|
|
|
|
|
You should. Dumb decisions are made all the time because some programmers are too lazy to do things right the first time and end up trying to perpetuate that decision by hacking up code to make their lazy code work.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
See this[^] series of articles.
/ravi
|
|
|
|
|
thanks Ravi, i already knew your article, and the software doesn't have problem for the serialization.
the point is much about having the 2 schema classes (so, duplicate classes names) in the same project...
|
|
|
|
|
Ah. It seems I've misunderstood your question.
Are you having problems differentiating between 2 versions of the same class when you read in the data? (If so, versioning the classes [as described in the tutorials] will take care of that.)
/ravi
|
|
|
|
|
nope, i read perfectly the files ((de-)serializing is not the matter at all).
i only fail in having two definitions of a class (in two different files) in the same project...
take this as an illustration of my problem :
MyClassOld.h :
class CMyClassOld {
private:
std::vector<CFoo> m_vecFooList;
std::vector<CFoo2> m_vecFoo2List;
};
MyClass.h :
class CMyClass {
private:
std::vector<CFoo> m_vecFooList;
};
what i want to do is this :
#include "MyClassOld.h"
#include "MyClass.h"
CMyClassOld o1;
CMyClass o2;
the problems curretly is that i have to rename one of the class into SomethingOld to avoid the "type redefinition" compilation error...
see what i mean ?
|
|
|
|
|
Gotcha.
I would take a different tack - use a single class (the latest version, without m_vecFoo2List). When you read the object's version during deserialization, use a local instance of std::vector<CFoo2> to read in the old data and ignore/convert it as required. This way, you only have a single class definition that supports both (and all future) versions.
/ravi
|
|
|
|
|
hum, yes, i see the point.
but what if the new business schema doesn't know its previous versions design ?
how do you think such a migration tool could be done ?
BTW, this is just a guess, for my curiosity, because everything works fine now (even if bad designed) and i think that your latest suggestion is the way to go...
|
|
|
|
|
toxcct wrote: what if the new business schema doesn't know its previous versions design ?
Ouch. That's a serious problem, since you can't do a silent upgrade (or a separate migration) without full knowledge of the old and new schemas.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: since you can't do a silent upgrade (or a separate migration) without full knowledge of the old and new schemas
that's why i was importing both classes version.
well, thanks Ravi, that was helpful  ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
Glad to be of assistance!
Btw, this[^] hack uses the serialization techniques described in my tutorial and is able to silently upgrade all previous 12 versions of its database without any intervention by the user.
/ravi
|
|
|
|
|
I'm including a CComboBox on the first CPropertyPage of a CPropertySheet displayed in wizard mode with the following styles for the property sheet PSH_WIZARD97|PSH_WATERMARK|PSH_HEADER.
The problem is that the drop down from the combo box is being drawn with the watermark bitmap as its background and I can't figure out how to stop it. Apart from anything else this makes it pretty hard to read the combo box text.
I realise this is probably something obvious but any help would be appreciated.
Thanks,
Ewan
|
|
|
|
|
in VS NET 2005 if you don't use the UNICODE libraries for your MFC application, then the edit control box (in form view or dialog) will be no longer flat. is anybody has any idea how to fix this?
cheers
|
|
|
|
|
I have a dialog class and another class that inherits from Cwnd. Call them class A and class B. They do not inherit from each other. However, i need for class B to have access to a member var in class A. Is the corect thing to do to have a pointer somewhere global to class A so that class B can use it when it needs it? If so, can someone help me with the syntax. I have tried different things and have been unsuccessful.
Thanks,
|
|
|
|
|
Please think about your design... otherwise, declare the classes "friend" as appropriate. For example, if you want to grant class A access to class B private areas, class B must state that class A is a friend.
Run-time - if you want access to the live data, well, you'd need to think about where you want the data and how the object instances know of the other.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
My other son commutes in an M1A2 Abrams
|
|
|
|
|
What is the "physical" relationship between class A and B ?
can't you pass a pointer a A to class B ?
|
|
|
|
|
I can do that but i think that the compiler gets confused when i do a double include...
e.g.
Class A : public CDialog
#include B.h
SetDlgPtr(this);
Class B : public CWnd
#include A.h
void B::SetDlgPtr(CA * pCA)
{}
|
|
|
|
|
This is a common problem. The solution is simple. In one of the .h files, don't #include the header file of the other class. Instead just put a forward declaration. For example, in b.h, remove #include A.h and put "Class A;". Then in b.cpp put the #include a.h.
|
|
|
|
|
what about creating a static pointer in the classes that you want to be able to use from any other class/function. then all you need to do is include the header for the class and voila!. For example:
<br />
<br />
class One<br />
{<br />
public:<br />
One(void);<br />
~One(void);<br />
public:<br />
void oneFunction();<br />
int oneX;<br />
<br />
};<br />
<br />
class Two<br />
{<br />
public:<br />
Two(void);<br />
~Two(void);<br />
public:<br />
static Two* m_ptrTwo;
<br />
void twoFunction();<br />
int twoX;<br />
};<br />
<br />
and the body...
<br />
<br />
#include "hello.h"<br />
<br />
<br />
Two*Two::m_ptrTwo = NULL;
<br />
Two::Two(void)<br />
{<br />
m_ptrTwo = this;
}<br />
<br />
Now we can use the pointer 'm_ptrTwo' to call anything in the public interface of the class Two. For example:
<br />
One::oneFunction()<br />
{<br />
Two::m_ptrTwo->twoFunction();<br />
Two::m_ptrTwo->twoX = 1234;<br />
}<br />
<br />
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
