• Create Account

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

20 replies to this topic

### #1RoundPotato  Members

Posted 02 September 2013 - 03:46 PM




### #2SiCrane  Moderators

Posted 02 September 2013 - 04:25 PM

If you can't figure out how to get boost to work, consider upgrading your compiler. Threading support is now part of the standard library as of C++11. std::thread is largely based on boost::thread and will work out of the box with a C++11 compiler.

### #3frob  Moderators

Posted 02 September 2013 - 04:28 PM

POPULAR

I need threads in my program

I'm curious.  Why?

Since you are posting in For Beginners, I would suggest that even if you want to add it, you should not add multithreading to your game. It is extremely unlikely that whatever you are developing actually needs multithreaded algorithms.

Multithreading is hard. Debugging in a multithreaded environment is very hard. When you are just learning to write games adding multithreading is just one more thing added to the long list of things you need to learn.  Becoming a game developer is hard enough with single-threaded games.

from what I know/read/seen Boost Threads are the best ?

They might be.  It depends on your situation.

I tested it under dev-c++

Dev-C++ is long dead, a quick search shows the last update was in 2005 and that there are several hundred known major bugs.

There are many free alternatives out there.  Visual C++ Express Edition, Code::Blocks, clang, and more. These are current compilers that are maintained and support the updates to the c++ language.

All of those compilers support threading out of the box since the new C++ standard includes a threading library.

It appears I need to compile/build them. The documentation is as weird as a round carrot ... It's like blinking an eye and an obvious thing for those who work with them, yet to a beginner like me it's a rock wall. Please help me drill that wall down

These are signs that you are probably not ready for multithreading.  Adding externally-built libraries to your program is a small thing relative to the difficulty of writing multithreaded code.

Eventually you will be ready for that kind of features. I recommend against them for now.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #4RoundPotato  Members

Posted 02 September 2013 - 04:50 PM



Edited by RoundPotato, 23 August 2014 - 06:03 PM.

### #5SiCrane  Moderators

Posted 02 September 2013 - 04:58 PM

Again, C++11's std::thread is based on boost::thread. The feature set is almost the same.

### #6RoundPotato  Members

Posted 02 September 2013 - 04:59 PM



Edited by RoundPotato, 23 August 2014 - 06:03 PM.

### #7SiCrane  Moderators

Posted 02 September 2013 - 05:05 PM

gcc is available on linux and has had support for C++11 since gcc 4.7.

### #8RoundPotato  Members

Posted 02 September 2013 - 05:18 PM



Edited by RoundPotato, 23 August 2014 - 06:03 PM.

### #9Satharis  Members

Posted 02 September 2013 - 06:39 PM

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

Thing is, you can put "no disrespect" on anything you like but from what I'm reading you seem very set on the idea that you know better than everyone here so I'm not entirely sure why you're even asking.

Threading for sockets is a legitimate practice but you can certainly do networking without needing multiple threads, there are non-blocking sockets for this reason.

The most flexible and low on resources implementation there is as well as most used, supported, proven, etc. etc. You know, the usual.

There's no "usual" in programming, what is good in one situation isn't good in another. The fact you don't seem to know that is rather scary. People have already mentioned that the C++ threading code is almost identical to the boost one so obviously it would be preferable to use the C++ standard library version unless you have either good reason to use the boost one or do not have access to it on your compiler.

I'm afraid you are wrong, please see http://orwelldevcpp.blogspot.com/ .

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

I wouldn't call a fork of an IDE to be the same as the original IDE, in fact if its a fork it shouldn't be using the same name in general.

What cracks me up in general is that you're so interested in having the "perfect" or "most optimal" library for a situation you don't even seem to be able to adequately explain, and ontop of that you're using an ide/compiler that I can almost guarentee does not have the same support or quality as half of what SiCrane just listed.

Visual studio doesn't even support all of C++11 yet and I believe gcc is still missing some as well, so it's not exactly unrealistic to think a fork of a long dead program might not support something like the new threading.

Not trying to be rude or anything here, just giving you a reality check. You're coming off more as trying to tell everyone they're wrong than to ask why they suggest what they do.

Edited by Satharis, 02 September 2013 - 06:39 PM.

### #10ultramailman  Prime Members

Posted 02 September 2013 - 06:59 PM

At the time of writing this, clang implements all of c++11.

### #11frob  Moderators

Posted 02 September 2013 - 07:03 PM

POPULAR

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #12RoundPotato  Members

Posted 02 September 2013 - 08:00 PM




Edited by RoundPotato, 23 August 2014 - 06:03 PM.

### #13SiCrane  Moderators

Posted 03 September 2013 - 10:42 AM

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.

### #14Xai  Members

Posted 03 September 2013 - 10:47 AM

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.

### #15RoundPotato  Members

Posted 03 September 2013 - 11:38 AM




Edited by RoundPotato, 23 August 2014 - 06:03 PM.

### #16NightCreature83  Members

Posted 03 September 2013 - 11:44 AM

I tested it under dev-c++

Dev-C++ is long dead, a quick search shows the last update was in 2005 and that there are several hundred known major bugs.

There are many free alternatives out there.  Visual C++ Express Edition, Code::Blocks, clang, and more. These are current compilers that are maintained and support the updates to the c++ language.

All of those compilers support threading out of the box since the new C++ standard includes a threading library.

Just as a side note but dev C++ latest stabel is from this year, someone took the project over in 2011. That being said you might stil be better off with a newer compiler as C++11 support will be better in those.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max

### #17Karsten_  Members

Posted 03 September 2013 - 03:51 PM

Some things that might help...

Regardless of IDE you use, you can get a decent build of g++ for Windows from here which supports the latest standard.

You need to make sure you are compiling with -std=c++0x or -std=c++11 in order to access the newer functionality.

I recommend modern C++ pretty much for better smart pointers to handle the threads (i.e custom deleters for shared_ptr) however, I find that pthreads on UNIX and pthreads-win32 for Windows to be perfectly usable and portable between almost any C++ compiler on any platform.

Also... you can still have a server listen and action connections without threads by using a polling type system (via poll(2) or select(2)). The only thing you will need to pull in threads for is if you want the same program to act as a server and a client (i.e to connect to its own server (i.e like Quake 3)).

Tbh, you shouldnt really need boost at all for this. Very similar to when people keep suggesting jquery to javascript developers for menial tasks, God kills a lovely fluffy kitten each time. (Sometimes boost *is* useful, in which case the kittens life is forfeit but that time is not now ;)

Edited by Karsten_, 03 September 2013 - 03:58 PM.

http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.

### #18nfries88  Members

Posted 03 September 2013 - 08:37 PM

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.

### #19RoundPotato  Members

Posted 04 September 2013 - 06:22 AM




Edited by RoundPotato, 23 August 2014 - 06:04 PM.

### #20NLScotty  Members

Posted 04 September 2013 - 07:15 AM

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.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.