Monday, November 7, 2022

Digest for comp.lang.c++@googlegroups.com - 7 updates in 2 topics

"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 07 07:48AM +0100

On 6 Nov 2022 23:30, Michael S wrote:
> of code written by non-specialist will do a better job than compatibility
> layer provided by standard C++ library, in particular one in
> std::chrono::stable_clock.
But here your belief is in direct conflict with reality.
 
The MinGW g++ chrono implementation has had (and probably still has) a
dynamically varying resolution down to 1/30 second, extremely unusable.
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Nov 07 07:20AM

> std::cout << nanosec.count() / (1000000000.0 * 60.0 * 60.0) << " hours since epoch\n";
 
> As I rarely need nanoseconds haven't tried it everywhere
> but at least looks portable.
 
I highly doubt that's going to return values at the nanosecond, or even
microsecond accuracy. (In other words, it's likely that the returned
value will jump by significantly more than a microsecond, at larger
time intervals, meaning that if you read the time again within that
time interval you'll just get the same value.)
 
Although, of course, this will depend on the target platform.
At a very minimum you can't assume the return value will have that
resolution.
 
(I don't know what guarantees the standard gives for this. Probably
none.)
Michael S <already5chosen@yahoo.com>: Nov 07 04:11AM -0800


> - Alf
 
> The MinGW g++ chrono implementation has had (and probably still has) a
> dynamically varying resolution down to 1/30 second, extremely unusable.
 
MinGW is obsolete since long ago, close to 10 years.
It is replaced by MSYS2/Mingw64.
Mingw64 had (has?) various problems with implementations of
std::chrono::high_resolution_clock and, may be (not sure)
of std::chrono::system_clock. But I don't suggest any of those.
I suggest std::chrono::steady_clock. It has reasonable
implementations on all x86-64 systems that I ever tested.
 
Anyway, it seems to me that OPs attitude is toward using
the most popular C++ tools on any given platform, i.e. MSVC on
Windows, LLVM/clang (via Xcode) on Mac and gcc on Linux.
Portability to more exotic tools+OS combinations is not required.
scott@slp53.sl.home (Scott Lurndal): Nov 07 02:39PM

>would not get 100% guarantee against name conflicts between multiple
>instances, but probability of conflict will be 3-6 orders of magnitude lower
>than any other time-based method.
 
If you are using the RDTSC instruction, be aware that the value returned
may vary based on the current clock speed; there are some chips where the
frequency of the clock RDTSC returns is invariant, others not so much.
 
https://stackoverflow.com/questions/4509727/how-to-detect-if-rdtsc-returns-a-constant-rate-counter-value
"Öö Tiib" <ootiib@hot.ee>: Nov 07 07:11AM -0800

On Monday, 7 November 2022 at 09:21:15 UTC+2, Juha Nieminen wrote:
> value will jump by significantly more than a microsecond, at larger
> time intervals, meaning that if you read the time again within that
> time interval you'll just get the same value.)
 
In some places it will work well enough for some use cases:
<http://coliru.stacked-crooked.com/a/a911aa914ed22a56>
As the calls themselves seem to take a microsecond that
resolution does not matter indeed.
 
> Although, of course, this will depend on the target platform.
> At a very minimum you can't assume the return value will have that
> resolution.
 
Anything can be not good enough for our case on some platform.
When I tried it worked well enough for what I needed in some places.
 
> (I don't know what guarantees the standard gives for this. Probably
> none.)
 
It does not matter as even when standard will give very good guarantees
then some of Microsoft, Apple, Intel, IBM, Google, Oracle, Texas
Instruments and what are they will anyway ensure that it does do
something odd on their platform or with third party compiler on their
platform or with their compiler on platform of someone else. The
engineers of those do not report to standard but to their peers who
report to shareholders.
 
It has been same all those decades.
Michael S <already5chosen@yahoo.com>: Nov 07 11:03AM -0800

On Monday, November 7, 2022 at 4:39:42 PM UTC+2, Scott Lurndal wrote:
> may vary based on the current clock speed; there are some chips where the
> frequency of the clock RDTSC returns is invariant, others not so much.
 
> https://stackoverflow.com/questions/4509727/how-to-detect-if-rdtsc-returns-a-constant-rate-counter-value
 
OP appears to wants unique number rather than real microseconds.
 
In today's x86 word RDTSC is based of "official frequency" of
given CPU model and is not related to actual current clock speed.
It was not universally so up until mid-00s, but we are in 2022.
But all that irrelevant for specific use case.
Juha Nieminen <nospam@thanks.invalid>: Nov 07 07:13AM

> won't bat an eye whereas static_cast will complain loudly. Ditto for
> many other mistakes which I might make. If you never make any mistakes
> when typing code, then it does not matter, but for me it does.
 
Indeed. In some cases eg. casting away constness may not only lead to bugs,
but in fact be UB. Such as casting away the constness of a char pointer
pointing to a string literal, and then trying to modify the contents of
that string.
 
With static_cast the compiler will tell you that you are trying to
cast away constness, and it may immediately indicate your error. With
a C style cast you might never notice, and the program may even seem
to work fine... until one day it doesn't.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)