• Advertisement
Sign in to follow this  

many potatersssss

This topic is 1601 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

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. 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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_

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement