Wouldn't hurt to define an operator<< for sf::Time, though...For what exactly? ???
Well, actually computers are so fast an asNanoSeconds would be needed to not loose precisionThat's not what I meant. When I say "lose precision", it's compared to what's stored in the sf::Time instance.
Though I see no need for implementing operator<< when everyone can just call a as(whatever)Seconds method to get the number.Absolutely.
Such an operator would be meaningful if it didn't just forward the call to asMicroseconds(), but output the value in a way that is recognizable as time. For example:I feel it's like with other requests that it doesn't really add anything that useful, but rather forces the user to one way. Everyone can already write a one liner to format the time in the way they want, thus is the gain bigger than the possible confusing among the users (e.g. "How do I make cout << myTime only display seconds?" etc.).32s 765ms 320us
But to do this, people would have to agree on a common format. So far, SFML doesn't overload the operator<< for I/O streams anywhere else (vectors, rects, colors, ...) -- why exactly time?That's the other thing, once we do it for one thing, we'll have to do it for the rest as well. It's basically just a functionality that's there for the lazy developers, because very rarely is one going to use an << for production code.
Btw., I was actually surprised a bit when finding out SFML is having a kind of very limited log-library hidden inside with the err stream. Adding a time to it may actually be a nice addition there, too. And if that would get implemented there are dozens other possible features for the log-library that may be nice, but I feel that distracts a bit from the M in SFML and may be something for a dedicated log-library.It's not a log-library and it should never develop into that. The reason sf::err exists is to give all the power to the user. If I want SFML's error not to appear on std::err it wouldn't have been possible to do so without sf::err (disregarding the idea of a global setting). With sf::err one can easily redirect the output. Forcing a timestamp would be quite bad as well. What if I have my own logger and want the timestamp to be format different or non-existing at all?
because very rarely is one going to use an << for production code.I would disagree on this. There's one very good reason why you might want to use << for production code — saving data to disk. Of course, this does assume you've decided on a plaintext file format, but there's nothing inherently wrong with that.
I would disagree on this. There's one very good reason why you might want to use << for production code — saving data to disk. Of course, this does assume you've decided on a plaintext file format, but there's nothing inherently wrong with that.Okay that was badly phrased, I actually wasn't thinking that much about logging with sf::Time, but was more thinking about outputs for sf::Vector, which aren't really useful with random characters in between. And of course the << operator is used in production code. ;)