[SFML 2.0 RC] - Threads

[kullerhamPster]

I just wanted to get an old (and never finished) project to work with SFML 2.0. I found out that there were lots of changes to the sf::Thread class, and I'm a bit confused why the 'old' way of creating threads (by inherting from sf:Thread and overriding 'Run()') was removed - I found this approach simple and elegant.
What's the reason for this change? Are there plans to reimplement the 'old' approach as an alternative?

[Laurent]

The new version is much cleaner and more flexible. The old way is just a very limited subset of the new API:

sf::Thread thread(this, &MyClass::Run);

[kullerhamPster]

I do not doubt that the new version is more flexible and powerful, but I'm not sure whether it's really cleaner.

If you have a class where each object should be 'active' (i.e., a separate thread), the old approach was well-suited and clean. I guess you could put the code you posted in the constructor of such a class to achieve that there's a thread per object without having to deal with Thread objects outside that specific class, but the resulting code  doesn't seem to be cleaner or simpler.

btw: Shouldn't the parameters in your example be the other way round? I don't find a matching constructor in the documentation.

[Laurent]

the resulting code  doesn't seem to be cleaner or simpler

It's cleaner because you don't inherit the public API of sf::Thread. It becomes a pure implementation detail. Well, you could use private inheritance but I think most people used public inheritance by habit.

btw: Shouldn't the parameters in your example be the other way round? I don't find a matching constructor in the documentation.

Oops, you're right. Sorry.

[kullerhamPster]

Thank you for your answer.

It's cleaner because you don't inherit the public API of sf::Thread. It becomes a pure implementation detail. Well, you could use private inheritance but I think most people used public inheritance by habit.

I know too little about C++ inheritance - why is it a problem if a class inherits the public API from sf::Thread? Being able to call something like myObject.Wait(); seems quite natural if the object runs within a separate thread.

Oops, you're right. Sorry.

No problem. I just was not sure if I correctly understood the API at that point. I'm not very good with that template stuff - probably that's the reason I liked the old API better

[Laurent]

I know too little about C++ inheritance - why is it a problem if a class inherits the public API from sf::Thread?

It's always better to decide which functions you want, with your own names and naming convention. Instead of being forced to adopt all the functions of sf::Thread (you most likely don't want terminate() in your own class), with the names that I chose (maybe you prefer join() to wait()), and the naming convention of SFML (maybe you prefer Launch() instead of launch()), etc.

It's not hard to forward functions of an internal member in your own class, but it's impossible to hide or rename functions inherited from a public base.

[Nexus]

I know too little about C++ inheritance - why is it a problem if a class inherits the public API from sf::Thread?

Additional to what Laurent said: The class has to know SFML and to depend on sf::Thread. In contrast, the current approach works with any callable type (function, functor, lambda expression), especially with already existing ones that aren't adapted to SFML.

[kullerhamPster]

Yes, the new approach surely is more flexible, and I don't propose to replace it with the old one. I was just wondering why the old way wasn't kept as an alternative (especially as the old API also offered a similar constructor, taking a function pointer).

[Laurent]

It is implicitely included in the new API, as I showed you above

sf::Thread thread(&MyClass::Run, this);

(in case you didn't notice, thread can be a private member of MyClass and be initialized in the constructor -- so from the outside point of view there's no difference).

There's really no need to rewrite the inheritance stuff in addition to that.

[kullerhamPster]

It is implicitely included in the new API, as I showed you above

sf::Thread thread(&MyClass::Run, this);

(in case you didn't notice, thread can be a private member of MyClass and be initialized in the constructor -- so from the outside point of view there's no difference).

Yes, I did understand that - it's more the "nicer and cleaner" argument from above (and perhaps backward-compatibility) that made me miss the old API a little bit.

[Foaly]

thread can be a private member of MyClass and be initialized in the constructor

How would you do that? Because I can't go like this:

//in the class header
sf::Thread thread;
//...

// in the constructor
thread = sf::Thread(&MyClass::Run, this);

because thread is NonCopyable.

[Nexus]

Use the constructor initializer list. You should always prefer it over assignments in the constructor body.

[Foaly]

Ah alright. Thank you very much!

[model76]

Use the constructor initializer list. You should always prefer it over assignments in the constructor body.

When I do that in Visual C++ 2010 it gives me a warning:

warning C4355: 'this' : used in base member initializer list

Is there a good way to avoid that, or should I just not mind? Simply suppressing the warning is not a good solution in my opinion.

[ccbsd]

I am sad it still can't run on FreeBSD.