|
|
what about
OLESTR
Tanvon
Tanvon
the brain behind ...
|
|
|
|
|
Hello,
How to retrieve the interface (ethernet) index on windows with winsock?
In Linux i use ioctl function, but in windows i use ioctlsocket, with this code
u_long iMode = 0;
if (ioctlsocket(s, FIONBIO, &iMode) == -1) {
printf("ERROR in ioctlsocket\n");
exit(1);
}
Can you help me?
thanks
-- modified at 11:24 Friday 18th August, 2006
|
|
|
|
|
I am breaking my project up into dlls. Now I have 1 class which I would like to turn into a dll, but there is a little problem. In my origional code, I pass the class a pointer to another class (simply to control a progress bar on the main window). If I do this in the dll I would need to include all the source files for the second class.
Now I only need 3 functions from the second class, what is the best way to go around this problem?
|
|
|
|
|
waldermort wrote: If I do this in the dll I would need to include all the source files for the second class.
It would just need to have the header file for the class included in the area you are using it, and the DLL that is trying to use the other DLL will need to be linked to it.
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 already tried that without success. I have 2 classes ClassA and ClassB. ClassA is in the main exe which creates an instance of ClassB which is in the dll. ClassB needs a pointer to classA so that it can adjust a progress bar.
When I include the header file for ClassA, I get unresolved external symbols for the three functions the dll uses (located in the main exe).
|
|
|
|
|
Perhaps adding the path to the .lib file for the DLL into your project will help with that.
|
|
|
|
|
waldermort wrote: I get unresolved external symbols for the three functions the dll uses (located in the main exe).
Ah, you said they were using functions in another DLL ... you can't link to an EXE, so you will get unresolved externals.
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 figured that what I was trying to do was impossible, so instead I stripped out the functions and added them to the dll. In the dll I then find the window handles for the controls and proceed as normal.
|
|
|
|
|
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).
Bad design.
waldermort wrote: If I do this in the dll I would need to include all the source files for the second class.
Simply post a message to the thread that owns the UI component. This is typically the primary thread.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Bad design.
I wouldn't call it a bad design when it isn't yet complete. Origionaly I started out with one class, after adding code I later had to break it into 5+ classes. I am now at the stage where I make the exe smaller and smooth out all these rough edges.
|
|
|
|
|
waldermort wrote: I wouldn't call it a bad design when it isn't yet complete.
Insomuch that one class should not have so much internal knowledge of another. It's the weak-coupling/strong-cohesion mindset. Should the progress control ever be changed to something else, those places that directly interface with it would need to be changed.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yes, but the cost of decoupling can be much greater than the cost of having to change all users of the class.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
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 ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
