cout operator << doesn't work for getElapsedTime ()

[Ardeshir81]

HI !
I'm new to sfml .
I was just testing time functions and I tried to use this :

cout << clock.getElapsedTime () ;

then i saw this error : "no match for operator << ..."

I tried this :

cout << (sf::Int64) clock.getElapsedTime () ;

BUT I got invalid cast error .

I'm wondering if there is any way to output elapsed time directly without converting it to sf::Time .
Thanks !

[eXpl0it3r]

It already returns an instance of sf::Time, which is why you can't use <<.
Simply add .asSeconds() or in whatever format you want it at the end.

[Laurent]

Don't forget to read the doc before asking questions on the forum.

[Celtic Minstrel]

Wouldn't hurt to define an operator<< for sf::Time, though...

[eXpl0it3r]

Wouldn't hurt to define an operator<< for sf::Time, though...

For what exactly?

[Celtic Minstrel]

For exactly this case where you just want to output the time and don't particularly care about the format... it could even print the units for you.

Of course, someone wanting that could just define it in their own program, so it's not really something important.

[Laurent]

The only thing that a generic operator<< for sf::Time could output is the time in microseconds (any other format would lose precision), which would print big numbers. Hardly readable or useful.

[wintertime]

Well, actually computers are so fast an asNanoSeconds would be needed to not loose precision. Only downside I can foresee is people asking why the clock steps in roughly 273nanosecond intervals or whatever the resolution of the currently used timer is and not single nanoSeconds.
Though I see no need for implementing operator<< when everyone can just call a as(whatever)Seconds method to get the number.

[Laurent]

Well, actually computers are so fast an asNanoSeconds would be needed to not loose precision

That'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.

[Nexus]

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:

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?

[wintertime]

Let me guess, people may want to log time since program start. Sadly converting the time, for example, to a nice "DD HH:MM:SS.UUUUUU" format takes a little more effort than printing x and y of a vector.
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.

[eXpl0it3r]

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:

32s 765ms 320us

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.).

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?
And finally it's again really easy to write your own logger and output your own timestamp without limiting anyone.
As a side note, such API changes would probably only be added for SFML 3 and if all goes well, we'll have exceptions there, so it's quite possible that sf::err will then disappear.

[Celtic Minstrel]

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.

[eXpl0it3r]

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.

Now that I think about this, it's not surprise logging came up earlier, because all such an operator does is add an easier way to log something, other than that it's not really useful, so the question we might want to ask ourselves, should SFML provide such "easy logging functions" and if so with what reason?

[wintertime]

I think a few people may like to have it, but I am of the opinion it should not be added in SFML (reading what I wrote above again it seems less clear about that than I tried to tell).