Does std::chrono replace sfml::Clock completely?

[LegumMan]

I just recently started learning the new stuff that comes with C++11. Custom implementations of timers made sense to me so far as there wasn't anything that simple in the std. But now there is chrono and I wonder if there is any reason not to use it.

From my amateur perspective Clock seems to be wrapping ctime to get around its ugly API (and perhaps smoothen out some implementation details?!). Chrono seems to be on par with Clock. Or is there something I'm missing?

[Nexus]

But now there is chrono and I wonder if there is any reason not to use it.

I'm not sure of the status quo, but high-resolution clocks were not used in all standard libraries, making corresponding code non-portable. And the syntax may be slightly more verbose, but of course you can use typedef/using and namespace aliases.

From my amateur perspective Clock seems to be wrapping ctime to get around its ugly API

No, sf::Clock wraps operating system specific APIs. <ctime> does not provide high resolution clocks. And the API is not ugly, just low-level C.

[infinitebox]

Does std::chrono replace sfml::Clock completely?

IMO, no. std::chrono was designed to be fairly generalized and does not provide a necessarily easy to use interface. sf::Clock is opposite of that. sf::Clock can use std::chrono internally if it wants to where it provides equal if not better precision than the platform specific APIs, but that's a different story.