SFML community forums

Help => System => Topic started by: vechestva on December 19, 2012, 08:10:50 pm

Title: SFML in the future.
Post by: vechestva on December 19, 2012, 08:10:50 pm
Will there be any in the library of methods for process management and implementation of the singleton pattern?


Sorry for my English.
Title: Re: SFML in the future.
Post by: Acrobat on December 19, 2012, 08:32:52 pm
Why do you need that in sfml pakage ? Let SFML be as simple as possible  ;)
Title: Re: SFML in the future.
Post by: Nexus on December 19, 2012, 08:34:51 pm
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.
Title: Re: SFML in the future.
Post by: eXpl0it3r on December 19, 2012, 08:38:27 pm
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...) ;)
Title: Re: SFML in the future.
Post by: Acrobat on December 21, 2012, 12:41:44 pm
SFML doesn't use it and thus doesn't need it
You are wrong. There are a lot of static vars in sfml.
Title: Re: SFML in the future.
Post by: G. on December 21, 2012, 01:01:17 pm
He's talking about singletons and you're talking about  static vars?  ???
Title: AW: Re: SFML in the future.
Post by: eXpl0it3r on December 21, 2012, 01:03:06 pm
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?
Title: Re: SFML in the future.
Post by: Acrobat on December 21, 2012, 01:04:14 pm
GlContext.cpp
Title: Re: SFML in the future.
Post by: FRex on December 21, 2012, 01:06:25 pm
Quote
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..
Title: AW: Re: SFML in the future.
Post by: eXpl0it3r on December 21, 2012, 01:17:41 pm
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...
Title: Re: SFML in the future.
Post by: vechestva on March 18, 2013, 09:59:44 am
Will there be moved methods getLocalBounds, getGlobalBounds to parent class?
Title: Re: SFML in the future.
Post by: eXpl0it3r on March 18, 2013, 10:08:31 am
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.
Title: Re: SFML in the future.
Post by: vechestva on March 18, 2013, 10:21:08 am
I guess the question is: Will getLocalBounds and getGlobalBounds get moved to the parent class? Right?
yep.

Quote
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.((
Title: Re: SFML in the future.
Post by: eXpl0it3r on March 18, 2013, 10:42:25 am
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. ;)
Title: Re: SFML in the future.
Post by: pdinklag on March 18, 2013, 10:58:37 am
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.
Title: Re: SFML in the future.
Post by: vechestva on March 18, 2013, 11:16:04 am
...
You do not understand me. I was referring to the cast to the parent class.
Example even have to SFML:
classes Shape, Sprite and Text are the methods of Transformable, so they inherit from him.
It follows from this that I can use methods getPosition() and I do not need to know which type is inherited particular instance Drawable.

for example:
void Object::Foo(sf::Transformable* transformable)
{
    ...
    transformable->getPosition();
    ...
}


sf::Shape* rect = new sf::RectangleShape;
...
object.Foo(dynamic_cast<sf::RectangleShape*>(rect));
 
Title: Re: SFML in the future.
Post by: vechestva on March 18, 2013, 11:33:30 am
Fixed the last post
Title: Re: SFML in the future.
Post by: Demone on June 03, 2013, 10:34:43 pm
the static variables are not singletongs in SFML case because are not accessible from outside directly. There very few. I can remember only VideModes and of course all GLfunctions adresses.

Always avoid Singletons. That's an antipattern.
Title: Re: SFML in the future.
Post by: Nexus on June 03, 2013, 10:59:47 pm
Please don't resurrect threads with a discussion that ended months ago...