of cross-platform threads and hate of libraries

[sourmìlk]

I hate using external libraries. I hate installing them, I hate learning how to use them, I hate that they don't behave exactly as I expect, I hate that I don't know exactly how they work. I only really use them if either a) they're built into the language / compiler (see: C++ STL) or b) they allow me to write cross-platform code. If I could, I would write my game engine entirely in assembly. No, I'd create my own video card and processor etc. out of silicon and then write drivers for everything and then write assembly code to compile a self-made language with which I would create 3D libraries that I'd extend into a game engine. But as that's not really feasible and as I like cross platform code, I'm using OpenGL, GLEW, and GLFW.

As for threads, there aren't really yet any cross-platform implementations of threads in C++. pthreads work for unix, but I want my engine to run on unix and windows systems. The std::thread class isn't coming out for a bit, and isn't yet available on MinGW. So what should I do to implement threads in my game engine? Should I write my own thread class that abstracts OS specific function calls? Should I wait for std::thread to become available on MinGW (how long would that take)? Should I cave and use boost? What should I do?

[letterX]

As for threads, there aren't really yet any cross-platform implementations of threads in C++

Boost is nothing if not cross-platform. I haven't actually used their thread library, but I keep reading the documentation and deciding that I'll use futures sometime in the future...

[sourmìlk]

Sorry, I meant "that come with C++". Do you think I should suck it up, use boost, and then transition when MinGW and xCode support std::thread?

[korona]

If you don't accept third party libraries you'll constantly have to reinvent the wheel. That is bad practice in software engineering.

By the way boost has such a high quality standard that their libraries could almost be considered part of the standard.
std::thread is boost's thread class in an different namespace.
std::uniform_int_distribution equals boost's uniform_int and so on. It does not just provide the same functionality, the implementation of those classes in gcc is a just copy of boost's code. gcc's implementation of the standard library makes heavy use of boost's static_assert and concept packages.

[Jplus]

In fact, not just GCC is making use of many Boost libraries. In many cases GCC is using Boost because those Boost libraries were added to the standard, just like Boost.Thread.

[gametaku]

In fact, not just GCC is making use of many Boost libraries. In many cases GCC is using Boost because those Boost libraries were added to the standard, just like Boost.Thread.

that is incorrect Boost was not added to the standard library. Well some features in C++ 11 such as threads and lambda's were influenced by the Boost, it is just that influence, and there are differences between them. Lambda's for example are a language feature not a library in the standard.

That said Boost is a great library to use in the cases where something is not part of the standard/supported by your compiler.

[EvanED]

In fact, not just GCC is making use of many Boost libraries. In many cases GCC is using Boost because those Boost libraries were added to the standard, just like Boost.Thread.

that is incorrect Boost was not added to the standard library. Well some features in C++ 11 such as threads and lambda's were influenced by the Boost, it is just that influence, and there are differences between them. Lambda's for example are a language feature not a library in the standard.

That said Boost is a great library to use in the cases where something is not part of the standard/supported by your compiler.

Really I'd say the truth is somewhere in between. For instance, take shared_ptr or the random library. While I'm pretty sure it's correct that technically speaking there are changes from the Boost version to the TR1 version, and from the TR1 version to the C++11 version, saying that the standard versions were "inspired by" Boost I don't think captures the depth of the import; they are nearly identical. They basically did pull in Boost and just add a few minor tweaks.

(I can't speak to the thread case in particular.)

[Sc4Freak]

The std::thread class isn't coming out for a bit, and isn't yet available on MinGW.

It should be pretty darn soon. C++11 has already been standardized. MSVC already ships with a complete C++11 standard library. I would expect Clang and GCC's implemenetations to come along fairly soon.

Should I write my own thread class that abstracts OS specific function calls? Should I wait for std::thread to become available on MinGW (how long would that take)? Should I cave and use boost? What should I do?

That depends entirely on what you want to achieve. If you're just doing this for fun (eg. reimplementing libraries for the sake of reimplementing them) the just go ahead and do whatever you want. Reimplement threads in assembly if that's what you want. But if you actually want to get something done, then use Boost and stop reinventing the wheel.

[sourmìlk]

I think that the term "reinventing the wheel" is unnecessarily derogatory. It's not like threading and game engines are so simple that making one is just like making a wheel, in that the outcome is identical no matter who has done it. When I make something, it is mine. Its structure and its behaviour is unique to me and it does what I want it to and it works how I find it intuitively should.

EDIT: I think the whole point is moot because I can't get boost to compile. I'll wait for std::thread -_-

[Jplus]

It's not like threading and game engines are so simple that making one is just like making a wheel, in that the outcome is identical no matter who has done it. When I make something, it is mine. Its structure and its behaviour is unique to me and it does what I want it to and it works how I find it intuitively should.

This is kind of true, yes... but do you realise that exactly because it's not as easy as making a wheel, you'll probably do a poor job compared to the professionals who implemented the existing solutions? And that it's taking you a lot of time to arrive at a mediocre result, while you could spend much less time to get a much better result?

Even getting Boost.Thread to compile will take you less time than implementing your own library. And with some luck, it will work out long before std threads are out.

[korona]

If you have a problem with a library and think that it does not meet it's specification why don't you just look at the library's code and fix that problem?
I'm 99% sure that boost was written by people who had more C++ and computer science knowledge than you have. Why do you think that your own approach will be better?
If you cannot get boost::thread to compile chances are good that your own library won't be very good either.

[Shivahn]

Also, if they don't behave as you expect, perhaps you could write some wrapper functions to call them such that they're closer to what you think they should be?

Another advantage to that is that later, you actually can go back and easily implement things however you want, then just change the wrappers themselves. You can basically then write programs using your own library before you write your library.

I mean, I'm sure you're likely doing that already, but perhaps it might help psychologically dealing with using other libraries by realizing that at any moment you could go back and implement them yourself and have few changes.

[sourmìlk]

It's not like threading and game engines are so simple that making one is just like making a wheel, in that the outcome is identical no matter who has done it. When I make something, it is mine. Its structure and its behaviour is unique to me and it does what I want it to and it works how I find it intuitively should.

This is kind of true, yes... but do you realise that exactly because it's not as easy as making a wheel, you'll probably do a poor job compared to the professionals who implemented the existing solutions? And that it's taking you a lot of time to arrive at a mediocre result, while you could spend much less time to get a much better result?

I'm sure that professionals have done excellent jobs implementing excellent libraries that I can't stand because I didn't make them.

[quote[Even getting Boost.Thread to compile will take you less time than implementing your own library.[/quote]
Not at this rate

If you have a problem with a library and think that it does not meet it's specification why don't you just look at the library's code and fix that problem?

Because that takes as long as learning the other person's library and requires at least as much empathy.

I'm 99% sure that boost was written by people who had more C++ and computer science knowledge than you have. Why do you think that your own approach will be better?

It's not that it will be objectively better, it's that it will be specifically what I want.

Also, if they don't behave as you expect, perhaps you could write some wrapper functions to call them such that they're closer to what you think they should be?

Another advantage to that is that later, you actually can go back and easily implement things however you want, then just change the wrappers themselves. You can basically then write programs using your own library before you write your library.

I mean, I'm sure you're likely doing that already, but perhaps it might help psychologically dealing with using other libraries by realizing that at any moment you could go back and implement them yourself and have few changes.

I think this is an excellent point. At the moment, I'm not going to use it because I have an irrational dislike of it.

[EvanED]

Even getting Boost.Thread to compile will take you less time than implementing your own library.

Not at this rate

What OS? And what complier do you want to use it with?

[sourmìlk]

Windows, MinGW.