Log manager

[Gawen]

Why do not implement a global log manager, with multiple level of detail, multiple source of log, etc ...

That could be useful for debugging.

We can imagine something like that :

Code: [Select]

log << log::level::GAME << "High level, game log." << log::end;
log << log::level::KERNEL << "Low level, SFML log." << log::end;

And developpers can set a log level and see more or less details.

Used in Linux I think.

[Laurent]

SFML uses the standard error output to log things, so you can already redirect it to whatever you want if needed. Then it's up to you to build a log manager, this is not a task for SFML

[Caspin]

I agree that it is not in SFML's scope to build a logging mechanism.  However, it would be nice if the library was more flexible about how it reported messages.
SFML could store an ostream instance with the system core.  System would then provide a mechanism to set the ostream used, it could default to std::cerr.  In this way the behavior hasn't changed but SFML gains the ultimate flexibility in reporting messages.

  A flexible error reporting feature would allow application to use that message data anyway the choose.  Capture it and display it in a message box, log it to a file,  send it out over a socket, all of the above, or some other bizarre use that neither you nor I could dream up.  It could even be used to cause SFML to throw exception instead of report errors, though admittedly that is a real kludge.  But it does go to show how much flexibility extending the error reporting system would give.

If there is interest I could provide a patch.  Then all you'd have to do is review the changes.  Which should be minimal, except for changing all to references to std::cerr to sf::System::err().

[Laurent]

You can already redirect std::cerr to wherever you want, I don't need to provide a new ostream. The only reason I see to do that, would be to be able to distinguish between SFML and another library that would also use std::cerr.