Provide sf::to_string() overloads for SFML types?

[Mario]

Just some random thoughts whether something like that would be feasible to have in the default codebase - analog to C++11's std::to_string().

I'm using such overloads for debugging purposes with events right now and I think it might be quite trivial to implement, but still really nice to have out-of-the-box, without providing any overhead to other functionality.

The actual value returned would either just be some generic string identifying an object (like "sf::RenderWindow"), but there could also be some more information or even actual content (like "sf::Vector<float>(4.31f, 24.21f)", "sf::Event::MouseMoved(524, 132)", or "sf::Color(255, 127, 127, 255)").

[Xornand]

I personally don't see much value in it, as you can just set breakpoints in the code and see the contents of each variable directly in the debugger.

[Mario]

Yes, as long as you've got a convenient way for breakpoints ... Not so great for realtime monitoring (e.g. on mobile) though, but at the same time that's again more like an edge case.

[Tank]

While I'd love such overloads, I think I wouldn't want them in the core library. An extension would be really nice, though.

[binary1248]

Not to mention, if you only plan to send them to some output stream, you can already provide the overloads yourself (the FTP example already does this), and as Tank said, this could be part of an external library as well.

[Kojay]

There are cases where logging is far more useful than the debugger's breakpoints; multi-threaded applications for one.

Qt offers a simple STL-like stream that can be used anywhere to output pretty representations of its classes. I made the suggestion for a similar stream in SFML:

http://en.sfml-dev.org/forums/index.php?topic=14708.msg103579#msg103579

Noone else seemed to care though.
A set of formatters for Boost.Log is another idea.

[Hiura]

When it comes to logging for debugging purpose, ask your debugger to print whatever you want and then continue automatically. I'm not saying you should never use a logger but if you need to print something for debugging your app, then editing it is not the best approach.

[Tank]

@Kojay: That looks good. Making the decision if something like that should be included in core would be easier if it would already be available as a working extension...