How should the code be organized?

[grok]

ILostMyAccount,
based on your example above I'd like to point out about the tricky (well, not so much, but still) moment about managing the allocated resources. In your version the Engine doesn't *own* the window, therefore it must not delete it in the current scenario. It is OK, but you have to deal with deallocation somewhere *outside* in case it was allocated on the heap.
This adds an additional burden to remember that.
The problem is that if you allocate window on the stack like below:

sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
Engine engine(&window);
 

you must not delete it from anywhere.
But, keeping in mind that your Engine takes a window by pointer, it makes things worse (it is not clear whether or not it should perform deallocation).

Therefore, I'd suggest that your Engine handle all the work related to window internally, i.e.: allocation and deallocation. In this case you won't need to remember about that moment, thus it'd lead to fewer possible mistakes.

Of course, it is personal and your approach works as long as you remember what you're doing.

Just my 5 cents.

[Ixrec]

Well, you should never have a raw *owning* pointer in modern C++ anyway.  You should only ever use raw pointers to *point* to something that somebody else owns (and only when references won't work for whatever reason).  So in principle that "should I delete it?" ambiguity should never even be an issue, but if nobody else in main() ever uses the window (an assumption I tried not to make earlier) then it's true that having it fully owned by the Engine would be simpler and clearer.

[cob59]

There's more than one valid way to structure these programs.  Yours is valid, but you haven't given any real reason why it's wrong for him to put the RenderWindow outside the Engine class, or not use the Engine::run() approach.

That's why I asked him first.
Variables should be declared as locally as possible, so if there's not a second Engine instance in his main that needs a reference to the renderer window, there's no point scattering his code across Engine.cpp and main.cpp.

imo a three-line main() like that simply makes main() a piece of meaningless boilerplate

That's the point : main.cpp becomes just a bootstrap and all your program logic is contained inside classes like Engine.
That's the Qt approach.

Those tutorials seem interesting, but I'm already seeing questionable stuff in them like manual new/delete

That's just a tutorial.
No need to add complexity by adding smart pointers everywhere.

lots of this->member instead of just member

I personally prefer the this->myAttribute notation over the m_myAttribute one.
Just a matter of taste.

We also don't know enough about ILostMyAccount's program to tell if he needs a top-level GameState stack, so we shouldn't be asserting that either.

He probably doesn't know either.
Trying to find the perfect-fitting code structure is pointless.
He just started SFML, he may be a bit lost, so he probably needs a quick HOW-TO with some basic game structure more than an exhaustive analysis on the subject.

Update: His second tutorial shows multiple draw functions with a clear(), a draw() and no display().  I think that's a severe enough mistake to warrant saying do not use these tutorials.

What are you talking about?
Link? Quote?

[Ixrec]

If you really want to argue this...

That's why I asked him first.

It doesn't count as asking if you don't wait for the answer.  But if there is no second instance, then yes it's simpler to put it in Engine.

That's just a tutorial.
No need to add complexity by adding smart pointers everywhere.
...
He probably doesn't know either.
Trying to find the perfect-fitting code structure is pointless.
He just started SFML, he may be a bit lost, so he probably needs a quick HOW-TO with some basic game structure more than an exhaustive analysis on the subject.

I was trying to point out that you were recommending a specific program structure when we have nowhere near enough information to tell if it's appropriate for whatever he's trying to do (and we still don't know what that is!).  For some reason you now appear to be accusing me of doing exactly that.  And I never said that he needs smart pointers; I said the state stack in those tutorials should *at least* be using smart pointers if not ordinary objects, but after further reading I don't think that stack needs to exist at all.

If anything, those tutorials are the antithesis of a quick how-to: Some of them end without a runnable program, the state stack is completely unnecessary since there are only two states (one of which is trivial), the texture manager doesn't do any managing and is also unnecessary, even if the stack was necessary the implementation is extremely circuitous (the items on the stack shouldn't be adding each other to the stack or calling functions on the stack's owner), and so on.  The same result could be achieved with a lot less code.

What are you talking about?
Link? Quote?

You already linked them, and I said "second", but...

https://www.binpress.com/tutorial/creating-a-city-building-game-with-sfml-part-2-the-first-state/124 contains these two:

void GameStateStart::draw(const float dt)
{
    this->game->window.setView(this->view);

    this->game->window.clear(sf::Color::Black);
    this->game->window.draw(this->game->background);

    return;
}

void GameStateEditor::draw(const float dt)
{
    this->game->window.clear(sf::Color::Black);
    this->game->window.draw(this->game->background);

    return;
}

I personally prefer the this->myAttribute notation over the m_myAttribute one.
Just a matter of taste.

To me the huge number of this->'s make the code a lot harder to read compared to a m_ prefix, and to be honest I was worried he didn't know the this-> was unnecessary in C++, but if that's actually a style some people prefer then I guess it's fine.

[SpeCter]

Why did you keep the sf::RenderWindow outside of your Engine?
You should make it a private attribute, initialized in the default constructor.
You basically need an extra method:

Update: His second tutorial shows multiple draw functions with a clear(), a draw() and no display().  I think that's a severe enough mistake to warrant saying do not use these tutorials.

No offense, but you didn't read his code carefully enough.He does use display(). He clears the screen twice(which is probably not what the author intended) but if you look at the game.cpp you will see that he calls display(), after he draws his stuff from whatever state he is in.

Not liking his code style is another thing though.The thing which I don't like the most is the fact that he writes return in void functions.

[Ixrec]

Why did you keep the sf::RenderWindow outside of your Engine?
You should make it a private attribute, initialized in the default constructor.
You basically need an extra method:

Update: His second tutorial shows multiple draw functions with a clear(), a draw() and no display().  I think that's a severe enough mistake to warrant saying do not use these tutorials.

No offense, but you didn't read his code carefully enough.He does use display(). He clears the screen twice(which is probably not what the author intended) but if you look at the game.cpp you will see that he calls display(), after he draws his stuff from whatever state he is in.

Ah, you're right, he does.  I guess it's not quite as bad then, though if even the author forgot he had a clear() call up in Game::gameLoop() when writing those draw() functions (and made me forget the display() was up there), that's still a strong sign that he's overcomplicated the basic game loop.

[SpeCter]

I would say, that you can't forget the clear and display in the gamestates(since you only need them once in the mainloop), which makes the code more failsafe. Not sure if that was the authors intent(he could have dropped the clear in his gamestates), but there is something positive about it

You are right that it is rather complicated for the result, but keep in mind, that the author intended the reader to extend it with the aquired knowledge, so it could very well be that you add more states like pause,options,game over, game won(however that would be achieved) and then it is not so complicated anymore

[Ixrec]

Well, in this case my real issue with the complexity is that the states are constructing each other and adding each other to the stack and accessing various things on the object that owns the stack.  So as implemented, adding additional states is likely to create a lot of bugs or subtle dependencies that newbies wouldn't even know to look out for.

If it was a *good* state manager, and there were one or two more states or transitions so that a newbie could get the idea of what this is actually for, and it was developed in a more iterative fashion (eg, start out with a simple switch() statement that will work and compile now, then make it complicated later), then I'd be all for it.

But we should probably wait for ILostMyAccount to return with an actual question.  Odds are none of this matters to him at all yet.

[ILostMyAccount]

Thank you for the answers.
Yes, a tutorial/guide or a good project to refer to would be nice, I'm just starting with SFML, I've read these: http://www.sfml-dev.org/tutorials/2.2/ but I really have no idea how to organize everything, I hate when I have too much stuff in my main if it's not necessary.

[SpeCter]

The way the code is structured in the tutorial is not that bad, if you take it with a grain of salt, but there is a book made from sfml members which is really good
And there is no optimal solution to how to structure your code. Some code structures are better then others for specific projects.

[Nexus]

http://en.sfml-dev.org/forums/index.php?topic=5187
...and many more