std::chrono is::a::fucking::pile::of::dog::shit. What a fucking disgrace. Hated it in boost, now this shit is in std. Each time I use it, I have to use google. Google should become part of std chrono in c++, without it you cannot write chrono code.

To make time_point member in your own class you have to do this: std::chrono::high_resolution_clock::time_point t; ... WTF

Write a wrapper if you can't remember. 🤷‍♂️

@BigBoo yes, that's what I do each time I need to access timers. I used to have wrappers for system specific clock APIs, now I do wrappers for std code. Why? It should be usable as-is. They should have provided int64_t time_ns() to get monotonic nanoseconds, or time_micro() or ms. That would cover 95% use needs that people have. All that moushfull::bullshit:chrono::talk is annoying as hell.

Just look at this disgrace:

std::chrono::high_resolution_clock::time_point t0 = std::chrono::high_resolution_clock::now();

runSomething();

std::chrono::high_resolution_clock::time_point t1 = std::chrono::high_resolution_clock::now();

std::chrono::high_resolution_clock::time_point::duration diff = t1 - t0;

std::chrono::microseconds micro = std::chrono::duration_cast<std::chrono::microseconds>(diff);

LOG("runSomething takes %llu microseconds", micro.count());

Yes, I know there is auto, but you cannot use it in class members. The point is: to represent timepoints, difference... all these basics suddenly became major pain in the ass when you really quickly want to measure some time

@pps83 Yeah. But you can typedef aswell right? ( I never typedef lol ) I get it that it's somewhat inconvenient. But it isn't garbage. Not even bad.

I usually only abuse the shit out of auto. And I don't usually need any time state in my classes. So maybe I don't have to suffer as much as you.

@BigBoo but all the functions and the rest there is the same type of crap. I did c++ for 15 years (and I loved it). I did some nodejs for a couple of years and now each time I need to write that type of chrono shit in c++ I feel that this does not make sense in 3rd millennium, I feel those dudes in std committee waste their time to come with ways for me to waste my time when I want to write some code. It's the same as dysfunctional std::string: you cannot even check easily if a string ends with some suffix. Finally these dudes ub committee after 10+ years decided to add it (we'll have it in std++20). Still std::string is crap. It's just a string-like interface bolt-on for std::vector.

I really want these things: cycle counter (or high res timer) as an int64_t, and a function that converts times to strings. I've done that soo many times and each time I want measure time I have to write tons of boiler-plate code. And to convert arbitrary durations to readable string is pure pain in the ass. That's what they should have added to std. Something that's usable, not some ikea-style set of bullshit tools for me to build my own tools.

@pps83 I agree totally with you that c++ isn't the nicest language to write in. Now, c++ is my favorite language. But I'm no fanboy. I don't think it's fitting for everything, not even a lot of things. But the performance is unbeatable for the usecases it's fitting for. Probably for things it's not fitting for. But it's fucking inconvenient to write in.

The std committee is ... Yeah. I agree. I think they are a bit too smart about things and don't see how productivity when writing code comes into consideration.

Every time I have to use std::chrono I need a couple of hours to calm down, it is ridiculously bad, verbose and inconsistent!

Want an integer duration in milliseconds?

uint32_t dur = std::chrono::duration_cast<std::chrono::milliseconds>(now_time - start_time).count();

Messy but at least you do not need to make any assumptions about what internal Klingon time units are used in your timepoints and the clock where they were took from. (Which is the only even barely excusable explanation to this syntax which looks like a bad case of diarrhea)

Want a duration in floating point seconds?

double dur = std::chrono::duration<double>(now_time - start_time).count();

Here, on the other hand, you need to known and trust that those timepoints and the clock that supplied them are indeed internally accounted in seconds and nothing else!

Also, count() returning a floating point value is definitely an oxymoron.