Then, I'm not certain about handling game screens (game states) making games with SFML. I declared an enumeration type for representation each of the states, but it's pretty clear to me that it's not sufficient since in every game state there is a set of objects (for example a text of welcome on the initial game screen, some background etc) that are created on switching to a state and destroyed on switching off to another. I of course could re-instantiate those objects over and over again while the game cycles through processInput(), update() and draw() just by declaring those objects in the methods, but I think it's too sily and ugly way of handling things like this. Moreover, in this case I have to set the origin, position, etc of the objects. For example, if I want a text to be displayed on the screen once the player loses the game, I'd have to declare a text variable, set its font, character size, string, origin, position right in the draw() method, which again seems not a very good practice. In addtition, there are some variables that must be re-assigned when the player causes the game come out of one state and get into another.
You can make a base class for state and child classes of it for each specific state, and create and destroy its objects in its constructor and destructor. Then you can make a state handler class that contains those states, in a container of type pointer of the state base class, and handles the switching.
You can even define specific processInput(), update() and draw() methods for each state so they can have different behavior. For example, a menu state only draws play and exit buttons while the game state draws the board and handles the game commands. On the state handler class you can set these methods too, to command the active state to call its respective methods.
Also, if you need to share resources among states, like textures, fonts, etc, you can declare them in the state handler class and share them to the states.