unsigned long milliseconds_since_epoch =
std::chrono::system_clock::now().time_since_epoch() /
std::chrono::milliseconds(1);
although, especially since you want platform independence, it might be better to replace unsigned long
with a type that's more likely to be large enough:
(unsigned) long long
std::(u)int64_t
std::chrono::milliseconds::rep
auto
To me, this clearly states both that you're risking loss of precision (by analogy with integer division) and that you're leaving the safety of the type system (by dividing by a typed time to give a unitless number). However, as demonstrated in the comments, some people would say that any attempt to move away from type-safety should be accompanied by a deliberate attempt to make the code look dangerous. If you need to deal with people who hold that belief, it might be simpler to use duration_cast
rather than enter into an argument about irrelevant stylistic choices:
unsigned long milliseconds_since_epoch =
std::chrono::duration_cast<std::chrono::milliseconds>
(std::chrono::system_clock::now().time_since_epoch()).count();
auto ms_since_epoch = duration_cast<milliseconds>(since_epoch);
already seems pretty simple. Perhaps the problem is the basic mindset ofchrono
where it's hoped that you'll stick with type safety and a richer type system than justunsigned long
. – bames53since_epoch
is just a stand-in variable forsystem_clock::now().time_since_epoch()
or whatever duration you want to convert. Usingauto
does not mean that code is not typesafe. In this case we explicitly state the type and we just useauto
so we don't have to repeat it. – bames53std::this_thread::sleep_for(microseconds(1000));
vs.std::this_thread::sleep_for(milliseconds(1));
. The library doesn't care what units the input is in. Both durations represent the same amount of time and that's all that matters here. – bames53count()
to get a unit-less value, you don't even need to useduration_cast
; simply usesince_epoch
in your calculations directly. – bames53