|
the char type has the range of -127 to 128. you want to use an unsigned char which has the range of 0 to 256.
|
|
|
|
|
Ok. I changed it and now the ctrl key is giving a value of 162, which is still not equal to VK_CONTROL (0x11).
|
|
|
|
|
It is however equal to VK_LCONTROL.
|
|
|
|
|
So every time I press the left control key I get a VK_LCONTROL value? Does that mean that the right control key is VK_RCONTROL?
If so, why did the vkcode equal VK_CONTROL a few days ago? I had a switch statement on logchar, and on case VK_CONTROL I would print out [CTRL]. It worked fine until two days ago.
Finally, are there any keyboard drivers that do not seperate VK_LCONTROL from VK_RCONTROL and instead just give a VK_CONTROL value?
Thanks for your help. 
|
|
|
|
|
I would like to know, the above mentioned,
for a car racing game,
would the server be able to handle say a thousand cars.
Can anybody suggest a means of testing such a venture?
I am working in MFC at the moment.
Thanks Simon.
|
|
|
|
|
|
One thousand sockets doesn't sounds like impossible. I guess you will hit limitations somewhere else, for example traffic limitation of your internet provider or performance bottlenecks in your server (who has to handle and distribute events to all clients).
Hope it helps.
|
|
|
|
|
I have an app that uses several CFormView objects. I set a default title to each of them when adding their frame windows to the document. I also set a new title in the OnUpdate function of these views based on the value of a member attribute. When the view is invoked it displays the title/caption in the title bar but, strangely, looses the title when loosing focus. The titles becomes ":1", ":2", etc. for these views if I switch from them to other views. To get back the title, I have to force an update so the OnUpdate gets called and the title is reset.
I am sure it's something very minor that's causing it but not sure what it is. Any feedback is very much appreciated.
|
|
|
|
|
Hi,
I want to split my window in 2 row but the below code is giving exception.
What is wrong with this?
<br />
CFrameWnd::OnCreateClient(lpcs, pContext);<br />
if (!m_wndSplitter.CreateStatic(this,2,1))<br />
return FALSE;<br />
<br />
m_wndSplitter.CreateView (0,0, RUNTIME_CLASS (CTreeFileRecovered),CSize (245,120), pContext);<br />
m_wndSplitter.CreateView (1,0, RUNTIME_CLASS (CListFileRecovered),CSize (100,400), pContext);<br />
<br />
return TRUE;<br />
|
|
|
|
|
Not enough info. What is the exception and what line of code is giving it?
|
|
|
|
|
|
Hello everyone,
I have made some experiment about poi command. But
always met with syntax error, here is my source code, and
related commands in WinDbg. My purpose is to deference
the memory which is holds by variable b, so that the value
of variable is displayed. Any ideas?
0:000> dv
b = 0x00000000`0012feb4
a = 200
0:000> poi (b)
^ pass count must be preceeded by whitespace error
in 'poi (b)'
0:000> poi (0x00000000`0012feb4)
^ pass count must be preceeded by whitespace error
in 'poi (0x00000000`0012feb4)'
#include <iostream>
using namespace std;
int main()
{
int a = 200;
int* b = &a;
return 0;
}
thanks in advance,
George
|
|
|
|
|
Hello everyone,
I think extern C is enough to prevent name from decorated, but when we export function names from a DLL using dllexport, even if we declare at the same time with extern C, but without a DEF file to define un-decorated exported function names, the name is still decorated.
I do not know why DEF file is needed? extern C is not enough to control name decoration for both DLL exported names and current DLL model linking?
regards,
George
|
|
|
|
|
George_George wrote: I think extern C is enough to prevent name from decorated
Don't think this is exactly true. C functions are also decorated based on calling convention.
See: http://msdn.microsoft.com/en-us/library/x7kb4e2f.aspx[^]
As an example; in .cpp:
extern "C" {
__declspec(dllexport) int MyFunc ( int A ) { return(A*2); }
}
and in .def (in EXPORTS):
MyFunc @3
'DumpBin /exports mydll.lib' will report '_MyFunc' as the name.
If, we used:
extern "C" {
__declspec(dllexport) int __stdcall MyFunc ( int A ) { return(A*2); }
}
then, even with the .def entry, dumpbin will report '_MyFunc@4' as the name.
What are you using to view the name ?
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Hi cmk,
Your reply is excellent. I have tried but have different results. In the document you recommended, it is mentioned default calling convention is __cdecl, and the resulting name in DLL should begin with sign _.
But my result is the default calling convention __cdecl results in name without _ sign? Here is my code and my output. Any ideas?
I am using VS 2008, Debug build for Win32.
D:\Visual Studio 2008\Projects\TestDll2\Debug>dumpbin /exports TestDll2.dll
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file TestDll2.dll
File Type: DLL
Section contains the following exports for TestDll2.dll
00000000 characteristics
48E8B6E6 time date stamp Sun Oct 05 20:45:26 2008
0.00 version
1 ordinal base
2 number of functions
2 number of names
ordinal hint RVA name
1 0 000110AF MyFunc1 = @ILT+170(_MyFunc1)
2 1 0001106E _MyFunc2@4 = @ILT+105(_MyFunc2@4)
Summary
1000 .data
1000 .idata
2000 .rdata
1000 .reloc
1000 .rsrc
4000 .text
10000 .textbss
extern "C"
{
__declspec (dllexport) int MyFunc1 (int A) {return 100;}
__declspec (dllexport) int __stdcall MyFunc2 (int A) {return 100;}
}
regards,
George
|
|
|
|
|
The default _cdecl is standard, the _ prefix is used by all vendors.
Other calling conventions are vendor specific (__stdcall is only MS i think).
Use extern "C" {} _and_ the default _cdecl when you want to create a dll with one compiler that can be called by an exe compiled using any other compiler.
If you have a .cpp file all functions will be named using C++ naming - mangled. If you have a .c file all functions will be named using C naming - mangled as described in the url i posted in previous message. The default _cdecl .c naming is considered by most to be unmangled, even though it is (leading _).
Using extern "C" in a .cpp file, or extern "C++" in a .c file, just allows you override the default naming the compiler uses based on the file extension (.c or .cpp).
In your dumpbin output MyFunc1 _is_ mangled (_MyFunc). The default is so standard that the _ is often dropped from display - but it is there.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
1.
If from dumpbin, we can not see the leading _ sign in my sample, then how could you find the leading _ sign is there? From which tool? Is it a bug of dumpbin which does not accurately?
2.
I am interested in your comments -- "extern "C++" in a .c file, just allows you override the default naming " -- do you mean using extern C++ in a .c file using C++ compiler, we could make the c program using C++ name mangling?
regards,
George
|
|
|
|
|
1.
Dumpbin is showing the leading _
1 0 000110AF MyFunc1 = @ILT+170(_MyFunc1)
it's the name on the right (_MyFunc1).
2. I mispoke, the compiler does not recognise extern in .c files.
extern "C++" would be used if nesting within an extern "C" block.
e.g. f.cpp
#define T_API __declspec(dllexport)
T_API int f_cpp1 ( int A ) { return(A); }
extern "C" {
T_API int f_c1 ( int A ) { return(A); }
extern "C++" {
T_API int f_cpp2 ( int A ) { return(A); }
}
T_API int f_c2 ( int A ) { return(A); }
} // extern "C"
T_API int f_cpp3 ( int A ) { return(A); }
In the above the nesting of extern "C++" overrides the extern "C" it is within.
See:
http://msdn.microsoft.com/en-us/library/0603949d(VS.80).aspx[^]
http://msdn.microsoft.com/en-us/library/s6y4zxec(VS.80).aspx[^]
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Hi cmk,
I read your above sample for point 2. My question is what is your purpose of showing this sample? To prove/show what point relates to my original question? 
regards,
George
|
|
|
|
|
?
The sample was a reply to your question about extern "C" and extern "C++".
It was to clear up what i had previously written.
It does not directly relate to your original question - other than to further point out that extern is not about controlling name mangling, it is about defining linkage; name mangling (or not) is a side-effect of the specified linkage.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
Understand and clear now. Two more questions for the link you provided,
http://msdn.microsoft.com/en-us/library/0603949d%28VS.80%29.aspx[^]
1.
"Microsoft C++ supports the strings "C" and "C++" in the string-literal field. All of the standard include files use the extern "C" syntax to allow the run-time library functions to be used in C++ programs." -- I am wondering whether the document is wrong? Using extern C should allow the run-time library functions to be used in C functions, since extern C specifies the C name decoration which could be consumed (linked) by C application?
2.
I also do not agree with this -- " C functions and data can be accessed only if they are previously declared as having C linkage. However, they must be defined in a separately compiled translation unit." -- we can define extern C function in the same cpp file (compiled translation unit) and use the function in the same cpp file, no need to be defined in a separately compiled translation unit.
regards,
George
|
|
|
|
|
1.
The document is correct.
Remember, extern <string> is C++ only, not C.
The C compiler will throw an "error C2059: syntax error : 'string'" if it sees extern "C".
This is why .h files will wrap extern "C" e.g.:
#ifdef __cplusplus
extern "C" {
#endif
... your C code
#ifdef __cplusplus
}
#endif
2.
I agree it isn't clear what they are referring to. I assume they mean 'C functions and data [in another comp unit] can be ...' which makes the 'However, ...' redundant.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
"Microsoft C++ supports the strings "C" and "C++" in the string-literal field. All of the standard include files use the extern "C" syntax to allow the run-time library functions to be used in C++ programs." -- after reading your comments, I think the quoted MSDN document means, for system runtime library (for example, I have examined math.h), it is all wrapped with extern C. It means the system library exports symbol using C name decoration.
- And for the header files, when used by C++ files (developer include the headers files in their C++ code), C++ compiler wil notice C name decoration is used and resolves name by C name decoration;
- And for the header files, when used by C files (developer include the headers files in their C code), C compiler wil ignore extern C since extern C is conditional compiled for C++ compiler only, and C name decoration is used by C compiler and resolves name by C name decoration.
All of my above understandings are correct?
regards,
George
|
|
|
|
|
"... used by C++ ..."
Correct.
"... used by C ... C compiler will ignore extern C ..."
The conclusion is correct, the reason is close.
It's not that the C compiler will ignore extern C, it is that the C compiler will not see extern C. The 'extern "C" {' is wrapped in '#ifdef __cplusplus' which will evaluate to false, so the C compiler never sees 'extern "C" {'. If it did see extern C it would throw an error.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
In VC environment, both C and C++ are using the same compiler -- cl.exe?
regards,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)