|
And if you took my advice and wrote the code the way it is supposed to be written it would probably be working by now. But you would rather come back with your usual whiny comments.
|
|
|
|
|
OK, I got it doing what I want putting all the requirements into a common header file and just including it in each class.
Here is my final question - does't compiler do each object file independently and linker puts them together?
That would explain why I need to redefine all. DEBUG and other.
Cheers
|
|
|
|
|
A compiler processes source files and creates an object file for each of the source files. These object files are then passed to the linker together with libraries to create an executable or a library.
The compiling process itself is not a single run but consists of multiple passes with three main tasks for the GCC:
- Running the preprocessor
- Compiling the intermediate file created by the preprocessing to assembly code
- Creating object files from the assembly code files
In your case it is all related to the preprocessor. That will look for the preprocessing directives (those beginning with #), process them and create an intermediate file. This intermediate file is then used for compilation. It will not contain #defines anymore.
If you want to see how it works, you can let GCC do each step separately and create corresponding output files which can then be inspected (use g++ for *.cpp files with *.ii as intermediate file extension):
# Run the preprocessor and stop
# The result is printed to stdout and redirected to a file
gcc -E example.c > example.i
# Compile passing the intermediate file and stop
# Creates assembly code file example.s
gcc -S example.i
# Compile passing the assembly code file and stop (do not link)
# Creates object file example.o
gcc -c example.s You might also use
gcc -save-temps -c example.c to prevent deletion of the *.i and *.s intermediate files so that they can be inspected.
|
|
|
|
|
Thanks,
I believe you are saying, in a different way , what I concluded.
Each source (.cpp) is being compiled interdependently therefore HAS to have all of the "parameters" In my case #define DEBUG use namespace std; and #include <xxx>
(there is another discussion about using namesapce std and cout).
I did added -v for verbose output from both compiler and linker and with little patience ( few lines of output ) I can see both processes.
Appreciate all who participated in discussion of actually very fundamental process as comping and linking.
Thanks everybody.
Cheers Vaclav
|
|
|
|
|
IS there a message map entry for this message, or maybe a virtual function has taken its place
|
|
|
|
|
Add it to some code and see if Visual Studio finds its reference. Or check the relevant section of the MSDN documentation.
|
|
|
|
|
let me clarify from the oninitdialog I did editcntl.Sendmessage(EM_SETWORDBREAKPROC,0,(LPARAM)editcntlwordwrap);
I had assumed based on the documentation
Quote: A Wordwrap function defines the point at which the system should break a line of text for multiline edit controls, usually at a space character that separates two words
that when I would type in a space my call back function would get control, this didn't happen. However I kept on typing and when I did get to the end of the line my call back function did get control
|
|
|
|
|
ForNow wrote: I had assumed
Not how I understand that note. It only makes sense to call the function at the point that a break is likely to occur, not for every space character.
|
|
|
|
|
There is never a message map entry by "magic". They are added manually or by the class wizard.
EM_* are messages send to an edit control for getting or setting properties, or starting specific operations. So there is no need to process these messages by your application and they are not supported by the class wizard. For most of these EM_* messages there are corresponding MFC functions which just send the message with some optional parameter processing. So you might for example override CEdit::GetSel() (which sends the EM_GETSEL message) to add some funcionality.
In the case of EM_SETWORDBREAKPROC your application would send this message to the control to pass the address of a function. Then there is no need to handle the message because you can do the necessary operations just before or after sending the message.
|
|
|
|
|
Let me clarify from the oninitdialog I did editcntl.Sendmessage(EM_SETWORDBREAKPROC,0,(LPARAM)editcntlwordwrap);
I had assumed based on the documentation
Quote: A Wordwrap function defines the point at which the system should break a line of text for multiline edit controls, usually at a space character that separates two words
that when I would type in a space my call back function would get control, this didn't happen. However I kept on typing and when I did get to the end of the line my call back function did get control
|
|
|
|
|
How is that related to your initial question about a message map entry or a virtual function for this message?
What you have quoted describes what the function usually does.
I have never used it but would expect that it is called when required (e.g. every time when reaching the line limit while typing and when "the user presses arrow keys in combination with the CTRL key to move the caret to the next word or previous word").
Have a look at the EditWordBreakProc callback function (Windows)[^]. It describes the actions passed to the callback function which indicate when it is called.
But it does not matter when it is called. You just have to return a value according to the requested action. For the case of word break checks (WB_ISDELIMITER), the return value is usually TRUE for a space.
|
|
|
|
|
I am getting an Error while compiling `DESolver.cpp`
DESolver.cpp: In member function ‘void DESolver::Setup(double*, double*, int, double, double)’:
DESolver.cpp:57:24: error: cannot convert ‘DESolver::Best1Exp’ from type ‘void (DESolver::)(int)’ to type ‘StrategyFunction {aka void (DESolver::*)(int)}’
calcTrialSolution = Best1Exp;
Detailed Error is shown Here
Complete Code
modified 29-Jan-21 21:01pm.
|
|
|
|
|
This appears to me to be a call taking a pointer to a function - it wants a pointer and didn't getting one. Add an ampersand and see how that works for you. This is a shot in the dark though because I do not see the code in its context or the prototype declaration of the function call in question. In other words, if you had posted more of the code you would likely receive a better answer.
|
|
|
|
|
Probably the ampersand will do the trick.
|
|
|
|
|
Instead of
calcTrialSolution = Best1Exp;
you have to write
calcTrialSolution = &DESolver::Best1Exp;
(so for all case statements, of cause)
|
|
|
|
|
Thanks It worked
modified 29-Jan-21 21:01pm.
|
|
|
|
|
Hi,
I have a server client application using TCP/IP sockets in MFC VS2017. Originally i have written the code in VS2008. Kindly see the below code which sends the data to client. But this same code gives me some problem in MFC VS2017.
In the below code when I assign the value 190.000015f to a local variable, its taking the value whereas when I assign it to the union member variable
UNI.S.fTestValue1
and
UNI.S.fTestValue2
it showing some junk value. Please help me to fix the problem
unsigned char* CSendValue :: SendLiveValues()
{
union USendLive
{
struct SSend
{
float fTestValue1;
float fTestValue2;
char cChr;
}S;
unsigned char Buffer[LIVEUNISIZE];
}UNI;
memset(UNI.Buffer,0,LIVEUNISIZE);
float fLocalValue;
float fTest;
fTest = 190.000015f;
fLocalValue = fTest; UNI.S.cChr = 'c'; UNI.S.fTestValue1 = fTest; UNI.S.fTestValue2 = 190.000015f;
return UNI.Buffer;
}
|
|
|
|
|
|
D.Manivelan wrote: it showing some junk value.
Where is it showing, and what value?
|
|
|
|
|
float fLocalValue;
float fTest;
fTest = 190.000015f;
fLocalValue = fTest; UNI.S.cChr = 'c'; UNI.S.fTestValue1 = fTest; UNI.S.fTestValue2 = 190.000015f;
Output
190.000015 - Correct value
'Ô' - Junk value - Wrong
6.360e-39#DEN - Junk value - Wrong
1.401e-45#DEN - Junk value - Wrong
|
|
|
|
|
Most likely you are not converting your values to/from network order when sending and receiving. See htonf function (Windows)[^].
|
|
|
|
|
The same code works fine in VS2008.
And moreover the issue occurs when I try to initialize the union member before actually sending the data to the socket.
My question is why I am not able to assign a float value to the union member which is also a float variable. This same line of code assigns the value in VS2008. Why its not doing it in VS2017
UNI.S.fTestValue1 = fTest;
UNI.S.fTestValue2 = 190.000015f;
|
|
|
|
|
Well since we have no real idea of what your code is doing to produce these bad values, it is difficult to offer any further suggestions.
|
|
|
|
|
This function returns a pointer to a local variable. If you want UNI.Buffer to continue to be accessible outside the function you have to allocate memory for it somehow.
|
|
|
|
|
Just to extend the reply of Graham Breach:
move the
union USendLive
{
struct SSend
{
float fTestValue1;
float fTestValue2;
char cChr;
}S;
unsigned char Buffer[LIVEUNISIZE];
}UNI; to the CSendValue class ctor to make the UNI a class member.
Then your CSendValue :: SendLiveValues() would look like
unsigned char* CSendValue :: SendLiveValues()
{
float fLocalValue;
float fTest;
fTest = 190.000015f;
fLocalValue = fTest;<br />
UNI.S.cChr = 'c';<br />
UNI.S.fTestValue1 = fTest;<br />
UNI.S.fTestValue2 = 190.000015f;
return UNI.Buffer;
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
