I'm trying to keep in mind that this is the For Beginners forum...

I'm afraid you are wrong, please see

That is not Dev-C++. That is a fork of Dev-C++ called "Orwell Dev-c++"

The two are very different. When you write "dev-c++" people will take that at face value, not assume you are talking about a fork of the product.

With those details we can see you are using either MinGW 4.7.2 or TDM-GCC x64 4.7.1.

Neither of those compilers supports C++11 threads. MinGW has stated in their documentation and even directly on their home page that they "do not, and never will" provide the full support needed. (They rely on the same library that uses std::thread as a wrapper of GThread which is a wrapper of pthread that is incomplete.)

It is of course your choice to pick a compiler that does not respect the C++11 standard.

Obviously I not only need them as common sense but I also need them at the moment for server side to listen and deal with multiple connections.

Thread-per-connection is not a solid design. It can work for trivial problems like simple file transfers, but for games it is usually a bad fit. Head over the Networking Forum FAQ #10 and #11 for some details on that.

The more common way to handle many collections is with connection pools and asynchronous calls.

There are many useful links to documentation and example source code in the Networking Forum FAQ. Those are not beginner techniques

C++11 is a relatively new "thing" and as I mentioned I was advised that Boost Threads are more "powerful" or "flexible".

If you want to learn Boost Threads, then do so. Boost has discussion groups where you can ask questions about it if people on this board don't have the answers you are looking for.

The C++11 thread library standard was based on the Boost implementation, and the Boost implementation was used for the reference implementations in several compilers.

It is no more powerful under just about any interpretation. The Boost library is more flexible in that you can modify the source directly if something about it does not meet your needs whereas the standard library implementation you cannot.

Unless you have specific reason to avoid it --- such as your decisions that prohibit the use of a modern compiler, or the preferred use of a specific operating system's native and more advanced functions --- c++11's threading functionality is comprehensive enough to handle most common needs.

Since for your own reasons you are choosing to use either MinGW 4.7.2 or TDM-GCC x64 4.7.1, that means C++11 functionality will not be available to you. So Boost or native functions are both good options.

No offence/disrespect on the following sentence meant(please): Yeah multi-threading is very scary....it's like an Armageddon... well, no, not really.

I wrote that multithreading is hard, not that it is scary.

On the surface you want to learn about threads. Great! Learning is a good thing.

In the process you will also need to learn about proper use of synchronization and locks and mutexes and semaphores, reentrant code, threaded storage, processing granularity, purity/isolation of data, memory barriers, CPU caches and cache coherency, and other topics. You will need to learn about the bugs that come with threading including deadlocks and livelocks, resource starvation, race conditions, memory thrashing, convoying, write tearing, and much more. Threading has even spawned a mathematical notation called transactional object calculus to help model the complexity of threading. It is an interesting topic and very much worth learning, just be aware of the scope.

In a university setting most schools will wait to cover the topic in depth until your fourth year, while other schools further delay it until graduate studies.

Again, I note that this is in For Beginners forum. Multithreading and parallel processing are an interesting topic, but it is complex and nuanced and generally not for beginners.





So trying to re-address the topic...

Your chosen compiler (either MinGW 4.7.2 or TDM-GCC x64 4.7.1, you didn't specify) does not support C++11's threading libraries.

Your chosen compiler also does not fit well with Boost's default configuration you will need to add several options to get it to work because the compiler uses a different toolchain than the default builder expects.

Once you've got Boost installed, the easy part is done. Then you have the introduction to Boost Threads, among those one of the gentler articles is
here.

You will probably also want to use Boost ASIO library for your network code since it plays well with the Boost Thread library. Google is your friend for documentation on that.

The purpose of the build process is not to produce source files. The source files already exist and can be found in the libs/ directory of the boost tarball. The purpose of the build process is to produce the static and dynamic libraries for boost with the tool chain specified. Building with MSVC produces MSVC libraries and building with gcc produces gcc libraries. You can't share the libraries between these two compilers for the same reason that you can't share any other C++ object file between them: the ABIs and object formats are incompatible.

There is no such thing as "typical" way to compile source cross-platform. You act like this is some simple thing where you copy the source into a folder and viola, it builds. That's not how truly powerful and low-level cross-platform C and C++ work. There are cross-platform considerations like processor architecture, pointer size, presence of math coprocessors, etc. And then there are platform differences related to software, which libraries are present, which versions, which other tools, etc. There are so many such little details that large, ongoing and complex projects exist solely to deal with these issues - such as gnu autoconf and the dozens of different dependency management systems out there.

When someone goes to create something like a THREADING library that works on multiple platforms correctly, what they are really doing is wrapping up dozens of DIFFERENT underlying platform specific APIs, with HUNDREDS of different variations, into something that is as close to a consistent API as possible given those underlying platform's differences. To this day, there is no such thing as a library that does this perfectly on all platforms ... no matter how you install, configure, compile and use it ... and you act like this should be some "simple" / "standard" thing that requires no thought to use. C and C++ are NOT like Java, nor .Net, nor Perl or any other newer, higher level language. They don't hide all the differences of each platform under some some simple common wrapper that makes you able to not care what compiler / tool-chain you are using .. because they expose those differences to you, the programmer.

C / C++ standards do not in any way dictate how libraries, projects, builds, etc. are created, loaded, or organized. They don't dictate a file format, they don't dictate even a linking feature set. The only thing C / C++ dictate is how to understand SOURCE CODE. But in the real world, source code depends on platforms and libraries to be useful, and all of this stuff is different on a Mac, onLinux, on Windows 32, on Windows 64 ... and different yet again for various versions and or tools within those larger labels.

You have to pick a platform, pick a language, pick a tool-chain and LEARN IT. Don't assume that every other platform, language or tool-chain should be the same ... learn one, use it ... and learn another someday if you want to. And don't assume it doesn't take work to learn something.

On a separate note, using boost this year is no longer necessary due to C++11, but is probably not a bad idea since it was well supported even before C++11, but within a few years it will simple fade out of existance as everyone migrates to the standard implementation. The reason this is so is that each compiler vendor (gcc, Visual Studio, Intel, etc.) wants their compiler to make the best and most performant code, and so they will be tweaking the implementations on their platforms ... and also, the whole point of a standard is to unify everyone's code to 1 version. And while there are custom libraries for special cases of EVERYTHING, when was the last time you thought to look for or learn an alternate to the C++ standard IO library, or template library, or math library? NEVER. Because it would be a complete waste of your time for 99.9% of all imaginable cases.

boost.threads provides an interface much like what you'd expect of the C++ Standard Template Library, which make it a good choice for people who like the conventions used by STL.

However, many game development frameworks (including SDL and SFML) already include functions to create and use new threads.

In reality, most thread APIs are more-or-less equivalent in terms of actual utility. If you're already using a library that includes it, or has a first-party extension library for it, I'd simply use their interface.

Thank you for taking your time to answer.

I was going to ask about how is that the case until I re-read SiCrane's post a few times and "googled" "ABI". It seems it cannot be as I expected it to be due to different implementations of an application binary interface for each compiler even on the same OS, correct ?

So to confirm I cannot test it in an efficient and fast way between OSs and compilers, the solution would be to compile the library for each compiler and for each OS ?

P.S I "act that it is simple" because I do not possess enough knowledge of the low-level interworking and nothing is left but to imagine it from what I know.

Yes, every compiler compiles different, the assembly code is not (without luck) the same, else there would only be one right?

Sometimes code might work for more than 1 OS, but sometimes code that works on win-7 doesn't work on win xp, due to WIN API changes or things none wants to know. You better choose an updated IDE and a OS you want to test your code on.