Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: [SFML 2.0 RC] - Threads  (Read 13776 times)

0 Members and 1 Guest are viewing this topic.

kullerhamPster

  • Newbie
  • *
  • Posts: 40
    • View Profile
[SFML 2.0 RC] - Threads
« on: June 03, 2012, 06:38:45 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: [SFML 2.0 RC] - Threads
« Reply #1 on: June 03, 2012, 06:48:40 pm »
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);
Laurent Gomila - SFML developer

kullerhamPster

  • Newbie
  • *
  • Posts: 40
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #2 on: June 03, 2012, 08:10:49 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: [SFML 2.0 RC] - Threads
« Reply #3 on: June 03, 2012, 10:15:22 pm »
Quote
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.

Quote
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.
Laurent Gomila - SFML developer

kullerhamPster

  • Newbie
  • *
  • Posts: 40
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #4 on: June 04, 2012, 02:03:27 am »
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.


Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: [SFML 2.0 RC] - Threads
« Reply #5 on: June 04, 2012, 07:57:48 am »
Quote
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.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: [SFML 2.0 RC] - Threads
« Reply #6 on: June 04, 2012, 05:58:27 pm »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

kullerhamPster

  • Newbie
  • *
  • Posts: 40
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #7 on: June 04, 2012, 06:54:09 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: [SFML 2.0 RC] - Threads
« Reply #8 on: June 04, 2012, 07:26:10 pm »
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.
Laurent Gomila - SFML developer

kullerhamPster

  • Newbie
  • *
  • Posts: 40
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #9 on: June 04, 2012, 10:23:39 pm »
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

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #10 on: June 07, 2012, 06:46:43 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: [SFML 2.0 RC] - Threads
« Reply #11 on: June 07, 2012, 06:51:45 pm »
Use the constructor initializer list. You should always prefer it over assignments in the constructor body.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #12 on: June 07, 2012, 09:07:01 pm »
Ah alright. Thank you very much!

model76

  • Full Member
  • ***
  • Posts: 231
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #13 on: June 09, 2012, 01:53:40 am »
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:
Quote
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

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: [SFML 2.0 RC] - Threads
« Reply #14 on: June 09, 2012, 05:00:47 am »
I am sad it still can't run on FreeBSD.

 

anything