|
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
|
|
|
|
|
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 />
|
|
|
|
|
I have seen some folks using HeapAlloc instead of malloc, how is that different?
thanks!
|
|
|
|
|
All my literature states they are basically the same. I guess portability would be the only difference. Malloc does not require a specific OS. HeapAlloc does.
But correct me if I'm wrong...
|
|
|
|
|
They are effectively the same. However malloc is in the C runtime libraries, so if you use it your application has to link in the C runtime. HeapAlloc is defined in kernel32.dll, so if you want to reduce the code size of your application you can avoid linking to the C runtime and use HeapAlloc to allocate memory.
Using HeapAlloc may make your code less portable if that is a concern for you.
I hope this helps.
Deus caritas est
|
|
|
|
|
Portability across different OSes or even across different flavours of Windows?
thanks!
|
|
|
|