I've decided my next little learning project would be threads, and I have an idea for a simple project to try it. I decided to try the thread library from Boost but I'm stuck on installation (haven't used Boost before). Most of Boost is just headers but the thread library is on the list of the bits that must be built separately. And ... it don't say how. Anyone got any pointers? Do I just go to the root directory and "make configure" then "make install"? This is MinGW btw ...

http://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html#or-build-binaries-from-source

Options you may find easier if you just need threads: Allegro 4.9 or pthreads.

I recommend staying away from boost threads. I did some work with them and it was a horrible mess using them, compiling them, packaging, etc.

pthreads i do recommend. they are the staple for threading and everyone learns pthreads in every university in the known universe.

I forgot about pthreads; I know I've heard that name before. I'll try those instead then. Thanks for reminding me.

There's also thread support built into SDL.

I second pthreads for their simplicity of use.

SDL does have threads, but the next major version of allegro will too. (No 3.4 isn't the next major version. )

Does pthreads allow you to lock threads to specific cores? (set process affinity etc.) I don't see anything about it in a brief Google session. I get the impression that this makes multithreading faster since there will be less code cache threshing.

Typically we let the operating system control thread affinity. There is a lot of research going on at the operating system level where they try and come up with the optimal thread schedule. Unfortunately, academics in computer science like to believe there can be an oracle and that computations have no overhead (both in die and in time).

Also, most GUI frameworks include threads support. So if you're using one of them, you can just stick with their own threading functions. In some cases they include some higher level functionality, so it's easier to get the job done (QT for example has QtConcurrent).

Of course QtConcurrent isn't exactly what everyone is looking for. QtConcurrent is more for spawning of self running parallelizable jobs.

If you are under windows, you can download prebuilt boost binaries from Boost Pro.

Boost threads are excellent, by the way. Better than pthreads (because they are object-oriented).

then the right command is:

bjam --build-type=complete gcc stage

according to the docs...

A couple of years ago I used Boost for some multithreading in a little networked game for communication threads. I don't recall any issues with installing it, I think I just followed a few online guides.

Anyway it worked great - it did exactly what it was supposed to and it was extremely easy to use once installed. I would certainly recommend it. It's just a bit shocking that you need an external library for multithreading in the first place... why don't you put C++ in the bin where it belongs and start using C#?

Meh; I'm already using C#. I am in fact spending my evening trying to get DirectX swap chains working so my rendering doesn't suck. Bloody hell is it complicated ...

Anyway I'm rethinking Boost threads since pthreads isn't object oriented, and the code is messier than I'd like as a result. I'm looking into both.

I don't see how object-oriented is better, its just different, and then limits it use to only C++. PThreads was designed to work in C, that happens to be usable from C++. This doesn't make it better or worse, just different. OO can be a drawback in many situations, when the problem being solved lends itself to procedural code. The fact that C++ can do both OO and procedural code is one of its strong points.

Boost threads go a step beyond pthreads in many situations, thanks to object orientation and other nifty c++ tricks.

I agree with axilmar and James, boost::threads are really neat and tidy compared to many of the other packages. And when doing multithreaded programming, you want all the neat and tidy you can get.

I got the VC 2009 SP1 DVD image, and installed C# just to test it a bit. It wasn't hard to get a "Hello World" program running, what was hard was trying to figure out where the executable was, there was a "setup.exe" that caused errors on another computer, but the rest of it was text files. Maybe this other computer lacked some .NET thing, but the whole thing reminds me of that maiden aunt that says "Oh! You don't want to do that! You want to do this other thing.

@axilmar, I would have argued more against your point, but with how mEmO phrased it, I can't argue with you. (Assuming that you were both meaning the same thing.)

I'm not sure about 2009, but AFAIK it still works the same. Your C# program (provided you chose "Windows Forms Application" or "Console Application" - web applications work differently) is compiled into a .exe which resides in yoursolution/yourproject/bin/debug or yoursolution/yourproject/bin/release by default, depending on your configuration. For most applications, you don't need anything but the executable (and, obviously, a .NET runtime that fits the compiler version; for 2009, you need .NET 3.5 if I'm not mistaken). If you have an App.config, you'll need to distribute that, too; and if you reference other assemblies (class libraries) outside the .NET framework, you need to distribute the dlls too (they are all copied to the same folder as your executable by default).

You can also add a "deployment" project to create an installer which contains everything you need on the target machine, including .NET.

Oh good Lord, I need to install the Boost:thread library, but I need to compile it with their compiler Boost Build, but that's a source distro that opens its documentation with how to compile it, so I need to compile the compiler so I can use it to compile the library so I can use it with the compiler I had in the first place. I don't even care if that works at this point; my shenanigans detector is approaching critical levels and I'm afraid it'll blow. I need to find another way to do this or just go work on something else ...

If I'm not mistaken the common build tool for boost is bjam and I seem to remember that this was available as an exe (at least for Windows). I also seem to have built the threads library (but I haven't used it), so it must be possible with bjam.

Oh good Lord, you didn't even bother reading the build instructions linked in the very first reply. If you had you'd probably have noticed a glowing linky with the text "download a pre-built bjam executable".

Yeah, that link takes me to a bunch of source distros. That's pretty much in line with my experience thus far.

I found a bjam lib but every time I try to do anything with it, including pass it the help flag, it gives me "Unable to load Boost.Build: could not find "boost-build.jam"". boost-build.jam isn't with the binary, and it's nowhere in the Boost lib. I'm putting this one to bed for now I think ...

Have you tried this? That seems to contain an .exe file.

But really... would it be hard of them to provide MinGW binaries? They are being very lazy, in my opinion.

Examples please ?

That OOP thingy always make me laught, specially now.

Are you really even trying at this point? The link takes you to 4 prebult binaries (BSD, Linux, OSX, WinNT) and 2 source packages. boost-build.jam is in the root of the boost source, exactly where it tells you to invoke bjam from.

example 1:

class Foo {
public:
    void bar() {
    }
};

int main() {
    thread t(bind(&Foo::bar, new Foo));
}

example 2:

mutex mtx;

int main() {
    lock_guard<mutex> lock(mtx);
}

example 3:

class Foo {
public:
mutex mtx;
};

int main() {
    shared_ptr<Foo> foo(new Foo);
}

It is quite possible that you are mixing up OOP (in the sense of polymorphism, great design patterns etc) with simply having RAII objects that automate cleanups and such tasks simply by having their destructor automatically called. RAII is immensely useful even in perfectly procedural code.

No, not at all. Bind produces run-time polymorphic objects and scoped locks use compile-time polymorphic objects, plus RAII is a great design pattern helped by objects.

Ok, but does that affect your programming style (except for making things more convenient )? If I write procedural code that uses char* for strings and I write the same code except using std::string (and worrying less about certain things), does that turn the design of my program into OOP?

2009? There is no such thing as VS 2009. Assuming you mean 2008, then yes, it works the same.

It depends on the code.

Typo.
Getting used to yet another year usually takes me about 6 months, I'm probably over-compensating by now.

No.

For your design to be OOP, it needs to follow the principles of OO design. For starters, read this.

Good. My point was that claims like "sometimes OOP is good, sometimes procedural is better" can't mean that "when procedural is better, you shouldn't use any objects like std::string or boost threads".