[SFML 2.0 RC] - Threads

[Laurent]

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

Using 'this' in the initializer list triggers a warning on VC++, yes. The only way to get rid of it is to disable it. Or to allocate your sf::Thread instance dynamically so that it can be constructed outside the initializer list.

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

If you have something relevant to say related to this thread, please say it clearly.

[Nexus]

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.

You can disable it locally with

#pragma warning(push)
#pragma warning(disable: 4355)

// code

#pragma warning(pop)

I wouldn't use dynamic allocations just to avoid the warning.

[Celtic Minstrel]

It's generally not a good idea to pass this in the initializer list because at that point it's not finished being constructed. However, in this case you know that Thread isn't going to access it until you later call .launch(), so it's safe to ignore the warning.

I don't think there's a way to avoid the warning given the current API.

[Laurent]

I don't think there's a way to avoid the warning given the current API.

There will be one when C++11 features are added: the move assignment operator.

[Celtic Minstrel]

Would that really be able to avoid the warning? I thought Thread didn't have a default constructor.

[Laurent]

I think it would have one in this case.

[Nexus]

I think it would have one in this case.

In case you mean "default constructor" with "one": Do you really want to allow invalid (default-constructed) threads to avoid this warning?

[Laurent]

In case you mean "default constructor" with "one": Do you really want to allow invalid (default-constructed) threads to avoid this warning?

Not just to avoid this warning, but to allow defining a thread after its construction, without forcing dynamic allocation.

[Nexus]

And what happens when launch(), wait() or terminate() is called on an invalid thread? I don't know if just doing nothing is a good idea...

[MorleyDev]

Launch: This is the one stickler. The stl gets around this because threads to launch as soon as constructed, instead of a manual launch function. I guess you could just make launch() throw or return some kind of error?

Wait: Would wait not just do nothing? It's a join command, a finished thread just keeps going here (well, with std at least throwing on any exceptions in the process), so I'd assume an invalid thread does nothing too...

Terminate: Is there a context in which SFML will be used where any way of forcibly terminating a thread is the best option? That aside, again how is are invalid thread and a finished thread different to an outside observer? Terminating a finished thread, presumably does nothing.

In the interests of honest, I've never used SFML's threading library. Always favoured boost threads, or C++11 threads when available (To simplify this I actually wrote a bit of code to drag in and turn a boost thread into the appropriate std:: versions with correct functions and parameters).

[Laurent]

If a default-constructed thread is considered "empty" (no function), it makes sense to do nothing in these functions.

Anyway, the problem is still: how to allow changing the definition of a thread after its construction, without dynamic allocation. It's not about allowing or not a default constructor

[MorleyDev]

Well without move constructors or similar (how boost fakes it), the only solution I can think of (and I'm sure you have already considered) is a "construct" or "setFunction" function or something? Which isn't the prettiest solution...

Then again, functionally I guess that isn't much different from a move constructor.

[Silvah]

In case you mean "default constructor" with "one": Do you really want to allow invalid (default-constructed) threads to avoid this warning?

Not just to avoid this warning, but to allow defining a thread after its construction, without forcing dynamic allocation.

With enough Boost, this is already kind of possible.

[Laurent]

With enough Boost, this is already kind of possible.

That works for people who use boost, but it would be cool to have a solution that works for others too, something built in SFML.

[Silvah]

That works for people who use boost, but it would be cool to have a solution that works for others too, something built in SFML.

Sure, I'm just saying that if someone badly needs that right now, it's possible.