Re: Sockets - Roughly, how many clients can a server handle for gaming purposes - C / C++ / MFC Discussion Boards

Re: Please help!!!! with 2 Dimensional array setup!!!!

Garth J Lancaster5-Oct-08 12:45

5-Oct-08 12:45

you havnt been around here for long, so you probably missed the bit that goes "we dont do people's homework/assignments/yada yada", even if we do feel a little sorry for them ...

If you post any attempt at code you've got we can use that as a starting point...

I'd suggest (since you say you're using c++) you look at :-

'string' : to hold the filename and a copy of each line in the file - you should only need two string instances to start with

ifstream : to access a data 'stream'/file for input

getline : to get one line of input from the stream/file into a string

while :(loop construct) to loop for all lines in the file until eof (end-of-file) is detected.

for starters.. you'll need to include appropriate headers - I'd suggest fstream, iostream and string ... once you can loop through a file and print its output to 'cout' or such, then think about how each line in the file needs to be split up/parsed to go into your array

'g'

LL_KEYBOARD hook problem

hxhl955-Oct-08 8:24

hxhl95

5-Oct-08 8:24

Hey everyone,

I've been getting some rather interesting results from my LL_KEYBOARD hook recently. Here is my code:

LRESULT CALLBACK LowLevelKeyboardProc (INT nCode, WPARAM wParam, LPARAM lParam)
{
	if (nCode < 0 || nCode != HC_ACTION)
		return CallNextHookEx( hKeyboardHook, nCode, wParam, lParam);

	KBDLLHOOKSTRUCT* p = (KBDLLHOOKSTRUCT*)lParam;
	char logchar=(char)p->vkCode;

It was working fine for a week, but I was adding KEYUP detection for the Ctrl, Alt, and Shift keys when it started giving me unexpected results.

The problem is that when I press the Ctrl key, logchar is equal to -72. I'm surprised by that, since I'm pretty sure the vkCode for the control key is 0x11. Because of this, I'm not detecting the Ctrl keypress, and ToAscii outputs the value for the ctrl key incorrectly. (It's outputting something that looks like a cent sign. If someone could explain why ToAscii accepts -72 as a valid vkcode that would also be appreciated)

The same problem occurs with any non-character key (except for space).

If anyone has any ideas on this I would highly appreciate it.

Thanks in advance. Smile | :)

Re: LL_KEYBOARD hook problem

PJ Arends5-Oct-08 11:24

PJ Arends

5-Oct-08 11:24

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.

Re: LL_KEYBOARD hook problem

hxhl955-Oct-08 14:16

hxhl95

5-Oct-08 14:16

Ok. I changed it and now the ctrl key is giving a value of 162, which is still not equal to VK_CONTROL (0x11).

Re: LL_KEYBOARD hook problem

PJ Arends5-Oct-08 16:56

PJ Arends

5-Oct-08 16:56

It is however equal to VK_LCONTROL.

Re: LL_KEYBOARD hook problem

hxhl956-Oct-08 7:10

hxhl95

6-Oct-08 7:10

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. Big Grin | :-D

Sockets - Roughly, how many clients can a server handle for gaming purposes

simon alec smith5-Oct-08 7:15

simon alec smith

5-Oct-08 7:15

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.

Re: Sockets - Roughly, how many clients can a server handle for gaming purposes

cmk5-Oct-08 16:26

cmk

5-Oct-08 16:26

The limit isn't likely going to be based on the network limits.
It will be based on the game engine and the way data is exchanged with the clients.

See: 4.8 How many simultaneous sockets can I have open with Winsock?
http://tangentsoft.net/wskfaq/advanced.html[^]

Also read up on how to impliment IOCP.
e.g. http://msdn.microsoft.com/en-us/magazine/cc302334.aspx[^]
http://www.codeproject.com/info/search.aspx?artkw=iocp[^]

...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

Re: Sockets - Roughly, how many clients can a server handle for gaming purposes

Moak6-Oct-08 23:18

Moak

6-Oct-08 23:18

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.

My webchat in Europe Java | [Coffee]

CFormView looses title on losing focus

bxveer5-Oct-08 3:44

bxveer

5-Oct-08 3:44

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.

CSplitterWnd

john56325-Oct-08 3:36

john5632

5-Oct-08 3:36

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 />

Re: CSplitterWnd

PJ Arends5-Oct-08 11:19

PJ Arends

5-Oct-08 11:19

Not enough info. What is the exception and what line of code is giving it?

Re: CSplitterWnd

Hamid_RT6-Oct-08 1:56

Hamid_RT

6-Oct-08 1:56

What's error?
And see Simple splitter with CWnd-derived panes[^].

poi command error?

George_George5-Oct-08 2:06

George_George

5-Oct-08 2:06

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

name decoration issue in DLL

George_George5-Oct-08 0:54

George_George

5-Oct-08 0:54

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

Re: name decoration issue in DLL

cmk5-Oct-08 2:05

cmk

5-Oct-08 2:05

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 ?

Re: name decoration issue in DLL

George_George5-Oct-08 2:49

George_George

5-Oct-08 2:49

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

Re: name decoration issue in DLL

cmk5-Oct-08 3:46

cmk

5-Oct-08 3:46

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.

Re: name decoration issue in DLL

George_George5-Oct-08 21:05

George_George

5-Oct-08 21:05

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

Re: name decoration issue in DLL

cmk6-Oct-08 2:50

cmk

6-Oct-08 2:50

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[^]

Re: name decoration issue in DLL

George_George6-Oct-08 22:53

George_George

6-Oct-08 22:53

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? Smile | :)

regards,
George

Re: name decoration issue in DLL

cmk7-Oct-08 4:54

cmk

7-Oct-08 4:54

?
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.

Re: name decoration issue in DLL

George_George7-Oct-08 22:18

George_George

7-Oct-08 22:18

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

Re: name decoration issue in DLL

cmk8-Oct-08 4:24

cmk

8-Oct-08 4:24

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.

Re: name decoration issue in DLL

George_George8-Oct-08 21:40

George_George

8-Oct-08 21:40

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? Smile | :)

regards,
George

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.