C++ Winsock Networking Tutorials [04-24-2017]

[albinopapa]

If you want to use Windows specific APIs maybe look at WinRT

No thanks lol, don't like the syntax, though after watching a CppCon video, I might not have to use WinRT directly. They came out with a C++ um, wrapper? for it. I don't remember the specifics, perhaps I'll look into it one day.

Thanks for the reply, I always took NULL as empty, which is why I think of it as a 0. Null terminated string == 0 terminated, so there's another connection to 0, where the VALUE '\0' or 0 is considered NULL. Since this is MY mindset, I find it harder to reason what the underlying variable is suppose to represent, a 0 value or a 0 address because so many use NULL for pointers even after nullptr was introduced. I'll just stay away from NULL all together, so there isn't any confusion.

[chili]

I mostly stick to std::thread stuff, but there is an argument to be made for using platform-specific APIs. The std library is made to be lean by design, and it also has to work at the LCD in terms of features. You can get access to more sophisticated/higher performance constructs by digging down into the WinAPI.

E.g I'm doing some tests on my Xeon system with 16 hardware cores. Since I am dealing with 2 NUMA pools, the ability to set processor affinity is paramount.

[LuisR14]

... is taking the fun out of programming, anyways, to consider NULL as an always-related-to-ptrs kind of concept just kind of seems contradictory (which i deem wrong for those other compilers to issue a warning, but what can i do *shrugs*), considering what albpapa mentioned

[reductor]

I mostly stick to std::thread stuff, but there is an argument to be made for using platform-specific APIs. The std library is made to be lean by design, and it also has to work at the LCD in terms of features. You can get access to more sophisticated/higher performance constructs by digging down into the WinAPI.

E.g I'm doing some tests on my Xeon system with 16 hardware cores. Since I am dealing with 2 NUMA pools, the ability to set processor affinity is paramount.

The standard isn't specifically about keeping things lean or targeting the lower-common-denominator, there are many things involved in the philosophy (Safety, Performance, etc).

Using OS API's don't always provide better performance, more then likely you will get equal performance. Performance should not always be your number one concern instead profile and then look at the problem instead of prematurely optimizing.

For doing things such as controlling processor affinity the standard provides std::thread::native_handle() for being able to call the OS functions when necessary.

... is taking the fun out of programming, anyways, to consider NULL as an always-related-to-ptrs kind of concept just kind of seems contradictory (which i deem wrong for those other compilers to issue a warning, but what can i do *shrugs*), considering what albpapa mentioned

I don't think it's a matter of taking the fun out of programming, understanding why to use one technique vs another technique is where alot of fun exists. Knowing the pros and cons is very useful.

The warnings are there for very good reasons, because people get things wrong and to provide better type safety. Not only that it is documentation for the code reader that (this is a pointer, this is 0)

[LuisR14]

... is taking the fun out of programming

I don't think it's a matter of taking the fun out of programming, understanding why to use one technique vs another technique is where alot of fun exists. Knowing the pros and cons is very useful

nah, ..was ..... referring to something else, ... although i agree about finding out the pros and cons by experimenting, and that surely would give way to \giving suggestions/ to the community.

The warnings are there for very good reasons, because people get things wrong and to provide better type safety. Not only that it is documentation for the code reader that (this is a pointer, this is 0)

in my code i'd be using (and have been) nullptr anyhow

[egizz983]

I heard the thing that Winstock is not a good idea for a Server Side is it a true ? and what then is the better for Server Side ?

And another thing is how to properly include winstock into Chili framework cuz i got tons of error once i tried , i also tried do like this :

Code: Select all

#include <WinSock2.h>
#include <Windows.h>

didt work

[albinopapa]

@egizz, I was able to include the Winsock2.h file just above the Windows.h file in ChiliWin.h

You need to make sure you add the ws2_32.lib somewhere
#pragma comment(lib, "ws2_32.lib")

I was able to put it in the MainWindow.cpp file after all the #includes and it compiled and ran fine, was even able to run the WSAStartup function.

[Pindrought]

I heard the thing that Winstock is not a good idea for a Server Side is it a true ? and what then is the better for Server Side ?

And another thing is how to properly include winstock into Chili framework cuz i got tons of error once i tried , i also tried do like this :

Code: Select all

#include <WinSock2.h>
#include <Windows.h>

didt work

It has been a while since I have done anything with the Chili framework. If you could post your solution, I will take a look at it to try to help you figure out how to properly include winsock.

[egizz983]

The i include Client.h inside a GameState.h

@egizz, I was able to include the Winsock2.h file just above the Windows.h file in ChiliWin.h

You need to make sure you add the ws2_32.lib somewhere
#pragma comment(lib, "ws2_32.lib")

I was able to put it in the MainWindow.cpp file after all the #includes and it compiled and ran fine, was even able to run the WSAStartup function.

i tried to comment that library just above winstock include that didt work for me

[Pindrought]

Move #include "Client.h" from GameState.h to MainWindow.h to be the first include.

This is required, because you need to include Winsock2.h before you include Windows.h

Also, since WinSock2.h will be included before Windows.h, you need to move #define NOMINMAX from ChiliWin.h to the beginning of Client.h before any includes.

I've attached the solution to this post.