Expose priv::ClockImpl::getCurrentTime() as sf::Time::getCurrentTime()

[FRex]

Why - because it might be super convenient at times.

Often I want to time something by just printfing some time stamps to console/file and look manually at the difference and now it requires me to stick a const sf::Clock somewhere (global) and call getElapsedTime().

Like come on... priv::ClockImpl::getCurrentTime() even already returns sf::Time.

It'd also make classes like stop watches (like the one in Thor) more idiomatic (IMO) by storing start and stop times, not an sf::Clock to use for literally that as well.

sf::Clock being made redundant by this is totally fine by me. There's many components already that are not wrappers over anything OS/library provided but are 'pure' SFML/C++ stuff made for convenience that power users don't use and that many other low level libraries don't provide (like shapes, sprites, text, unicode string conversions, etc.).

[Laurent]

The problem with such a function is that we only know that it returns a time. We don't know it's reference. So it is only suitable for measuring delta times. Which is fine, but...

sf::Time getCurrentTime()
{
    static sf::Clock clock;
    return clock.getElapsedTime();
}

... is doable with the current API and makes it clearer what the time reference is.

[FRex]

We know it's monotonic so it's good for deltas which is what I wanted anyway.

This function with static sf::Clock also has a weird 'reference', first call will be 0 or very close to 0, and the clock starts from then on. It's also only good for deltas unless you call it as soon as you enter the program to make it a 'program running' clock (which has other problems).

And it's silly and cumbersome (I now either need to write it when I want a quick two printfs somewhere or keep it in some header I use) to get what I want by wrapping a class which wraps what I want internally, all just because that one function isn't exposed.

And it relies on sf::Clock not causing problems by being a static local (which it doesn't but other/GL classes will so suddenly if you want it you need to know what's okay to break the "don't make SFML classes static/global" rule with and what isn't).

[Laurent]

We know it's monotonic so it's good for deltas which is what I wanted anyway.

Yes, that what I said, it's good for deltas.

This function with static sf::Clock also has a weird 'reference'

This is just an example, the good thing with user written code is that you can decide what you do. For example, you could write a "timeElapsedSinceAppStartup" function if you needed to. And in any case, it's not as weird as being OS-dependant, undocumented and potentially different in future versions of SFML.

It's also only good for deltas

Yes, since that's what you wanted. But you wrote it, so the constraints on it (documentation, consistent behaviour, etc.) are a lot relaxed compared to the same thing put in a middleware.

And it's silly and cumbersome

You want to measure delta times, which is exactly what sf::Clock does. I don't think it's silly or cumbersome.

I now either need to write it when I want a quick two printfs somewhere or keep it in some header I use

So as many useful things

And it relies on sf::Clock not causing problems by being a static local (which it doesn't but other/GL classes will so suddenly if you want it you need to know what's okay to break the "don't make SFML classes static/global" rule with and what isn't).

It's not constructed before main(), unless you call that function to initialize a global variable. So that rule doesn't apply here.

[FRex]

Ok. Well, I tried.