SFML in the future.

[vechestva]

Will there be any in the library of methods for process management and implementation of the singleton pattern?


Sorry for my English.

[Acrobat]

Why do you need that in sfml pakage ? Let SFML be as simple as possible 

[Nexus]

No, there won't be, since the topics you mentioned are not related to multimedia.

If you mean threads with "process management", then yes, they are already part of the SFML functionality. For more elaborate multithreading, you can use the C++11 standard library or Boost.

[eXpl0it3r]

Will there be any in the library of methods for process management and implementation of the singleton pattern?

No and no...

I don't really understand what you mean exactly with process management, but that alone already shows that this topic is far too big and for every OS vastly different. On top of that I don't think it would fit anywhere into the Simple nor Multimedia.

In good C++ code are singletons considered bad practice. SFML doesn't use it and thus doesn't need it, so there most certainly won't be anything in that direction. Try to avoid the singleton patter as much as possible. (Just search a bit on the forum for our various discussions from the past...)

[Acrobat]

SFML doesn't use it and thus doesn't need it

You are wrong. There are a lot of static vars in sfml.

[G.]

He's talking about singletons and you're talking about  static vars? 

[eXpl0it3r]

You are wrong. There are a lot of static vars in sfml.

Static variables and the singleton pattern are two vastly different things. I haven't read through the whole codebase, but as far as I did, I couldn't see the use of the singleton pattern.
Also you should read a bit more about it to see that in 90% of the cases where it's used, it's bad/wrong to use it and there are more elegant ways in handling things.

Can you show me some examples where SFML uses a lot of static vars?

[Acrobat]

GlContext.cpp

[FRex]

I haven't read through the whole codebase, but as far as I did, I couldn't see the use of the singleton patter.

https://github.com/SFML/SFML/tree/master/src/SFML/Graphics
ImageLoader.cpp and .hpp, not that there's something wrong with that use..

[eXpl0it3r]

GlContext.cpp

It's just one static function and has nothing to do with singletons...

@FRex: Thanks, I didn't know.

Anyways there's no reason/need to provide a baseclass for singletons. It would not only lead beginners into believing that it's good to use the pattern, but it will probably also increase the help requests in the forum, because of some sideeffects of global variables etc...

[vechestva]

Will there be moved methods getLocalBounds, getGlobalBounds to parent class?

[eXpl0it3r]

Please create a new topic or find one that actually suits your question nexttime. This thread was about features for Process Management and Singleton Pattern.

Will there be moved methods getLocalBounds, getGlobalBounds to parent class?

I guess the question is: Will getLocalBounds and getGlobalBounds get moved to the parent class? Right?

If so then the answer is no.
The two functions exist only for convenience and not all of the transformable would need those functions. Besides that it's very easy to add such functionality to a derived class, if you need them.

[vechestva]

I guess the question is: Will getLocalBounds and getGlobalBounds get moved to the parent class? Right?

yep.

If so then the answer is no.
The two functions exist only for convenience and not all of the transformable would need those functions. Besides that it's very easy to add such functionality to a derived class, if you need them.

This is problematic in my situation.
For example, I want to write a common function of demand for Drawable, but the methods of getGlobalBounds and getLocalBounds declared  separately in each class (Shape, Sprite, Text,  VertexArray?).
I make do with templates and type checking.((

[eXpl0it3r]

For example, I want to write a common function of demand for Drawable, but the methods of getGlobalBounds and getLocalBounds declared  separately in each class (Shape, Sprite, Text,  VertexArray?).

Well they are completely different classes and thus it would even be impossible to write a generic function to do this for all the different types, especially since VertexArrays and the other classes don't share a common interface at all.

But you can easily create some free functions of your own and do the calculations there for each different type.

[pdinklag]

You're also using SFML in a "wrong" way then. SFML is not a framework. If I understood Laurent right, the class abstractions are not a design choice that people should rely on, but a simple way of re-using code. Obviously, the boundary calculation for sprites is fundamentally different from the calculation for texts, so there is no re-usable code here, that's why there is no abstraction for it.

If you need abstractions like the one you mentioned, you should design your own framework that uses SFML, not one that builds on it.