This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Default to --enable-libstdcxx-time=auto


On Sat, May 25, 2013 at 08:21:46AM +0200, Jakub Jelinek wrote:
> In this _V2 inline namespace, I think we should change that:
>     struct system_clock
>     {
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
>       typedef chrono::nanoseconds                               duration;
> #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
>       typedef chrono::microseconds                              duration;
> #else
>       typedef chrono::seconds                                   duration;
> #endif
> into:
>     struct system_clock
>     {
>       typedef chrono::nanoseconds                               duration;
> 
> Won't the templates then DTRT in:
>   return time_point(duration(chrono::seconds(tv.tv_sec)
> 		    + chrono::microseconds(tv.tv_usec)));
> (multiply microseconds by 1000 and seconds by 1000000000)
>       return system_clock::from_time_t(__sec);
> (multiply seconds by 1000000000)?
> 
> While this change isn't really necessary for Linux, where usually
> _GLIBCXX_USE_CLOCK_REALTIME will be in 4.8.1+ defined and thus the
> nanoseconds resolution will be used anyway, on other OSes it might
> be already a problem, say on Solaris or FreeBSD GCC 4.8.1 will have
> by default likely microseconds resolution, while on the trunk nanoseconds.
> By making it always count in nanoseconds, even if on some OSes the low
> 3 or 9 decimal digits will be always zero, we'd prepared to change the
> system_clock::now() implementation any time to provide better resolution, as
> a libstdc++ internal implementation detail.
> 
> Or is this undesirable for users for some reason?

Additional comment to that, the fact that the OS has clock_gettime with
CLOCK_REALTIME resp. gettimeofday still doesn't say anything about the
resolution/precision of the clock, you can have clock_gettime
(CLOCK_REALTIME, &tp) that only provides second or millisecond resolution,
or hundreds if microseconds, tens of nanoseconds etc.  There is clock_getres
in POSIX, but <chrono> doesn't query this and if the resolution decision
has to be static (nanoseconds vs. microseconds vs. seconds), I'd hope it
should be ok to always use nanoseconds duration, especially when most of the
important targets will either in 4.8.1+ or at least in 4.9.0+ use
clock_gettime.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]