Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Provide sf::to_string() overloads for SFML types?  (Read 4433 times)

0 Members and 1 Guest are viewing this topic.

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Provide sf::to_string() overloads for SFML types?
« on: August 26, 2014, 09:44:48 pm »
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

  • Jr. Member
  • **
  • Posts: 78
  • C++ / Python
    • View Profile
Re: Provide sf::to_string() overloads for SFML types?
« Reply #1 on: August 26, 2014, 10:59:51 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Provide sf::to_string() overloads for SFML types?
« Reply #2 on: August 27, 2014, 12:06:03 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Provide sf::to_string() overloads for SFML types?
« Reply #3 on: August 27, 2014, 12:56:33 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Provide sf::to_string() overloads for SFML types?
« Reply #4 on: August 27, 2014, 01:52:06 pm »
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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Kojay

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: Provide sf::to_string() overloads for SFML types?
« Reply #5 on: August 27, 2014, 02:28:10 pm »
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.
« Last Edit: August 27, 2014, 02:36:29 pm by Kojay »

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: Provide sf::to_string() overloads for SFML types?
« Reply #6 on: August 27, 2014, 03:46:53 pm »
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.
SFML / OS X developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Provide sf::to_string() overloads for SFML types?
« Reply #7 on: August 28, 2014, 08:31:26 am »
@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... ;)

 

anything