When i am in a get_sting_input function thats in the hi_score_menu function thats in the game_over_scene function thats in the main function and the user just presses the exit button of the window, it was a pain to get the quit flag to main.. But from what i understand, it's not the implementation of quit thats wrong, its that i'm layering too much..
[/quote]
This sounds like get_string_input has its own input loop?

I would generally model it differently. For simple games, game over/high score are not functions, but states. Control is continually passed from the main loop into the active state: to react to input, update and render.

In simple games the active state can be an enumeration, with a switch in main() to pass control to the correct states. Something like this:

enum GameState
{
MainMenu,
RunGame,
GameOver,
HighScore,
Exit
};

int main(...)
{
setup();

GameState current = MainMenu;
while(current != Exit)
{
SDL_Event event;
while(SDL_PollEvent(&event))
{
switch(current)
{
case MainMenu: handleMenuEvents(event); break;
case RunGame: handleGameEvents(event); break;
case GameOver: handleCutSceneEvents(event); break;
case HighScore: handleHighScoreEvents(event); break;
}
}

GameState next = current;

switch(current)
{
case MainMenu:
next = updateMenu();
renderMenu();
break;

case RunGame:
next = updateGame();
renderGame();
break;

case GameOver:
next = updateCutScene();
renderCutScene();
break;

case HighScore:
next = updateHighScore();
renderHighScore();
break;
}

if(current != next)
{
transition(current, next);
current = next;
}
}
cleanup();
}

In more complex games with lots of per-state information, I might model each state as a class that implements an interface, with pure virtual update(), onEvent() and render() member functions. I would use a class to leverage RAII for setup/teardown of the per-state data.