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 24 May 2013 21:10, Jakub Jelinek wrote:
>
> So, there is a minor issue that what is std::chrono::steady_clock has
> changed, if you say use it as a function parameter, it will mangle
> differently before/after.  Guess not that big a deal, after all, C++11
> support is still experimental, right?

Right.

> But the more important issue is that std::chrono::system_clock broke,
> code compiled against the old headers will assume
> std::chrono::system_clock::duration is microseconds resolution on Linux,
> while code compiled against the new headers will assume it is in
> nanoseconds resolution.  That is because of:
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
>       typedef chrono::nanoseconds                               duration;
> #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
>       typedef chrono::microseconds                              duration;
> #else
>       typedef chrono::seconds                                   duration;
> #endif
>
> Thus, I'm afraid we can't ABI compatibly change either of these macros,
> unless we e.g. keep old std::chrono::system_clock as is and introduce
> std::chrono::__whatever::system_clock or whatever, that will be typedefed
> as std::chrono::system_clock.

Or use the new ABI attribute so the "new" system_clock mangles
differently to the "old" system_clock.

I prefer to break it though - if we're going to paint ourselves into a
corner and insist on compatibility with semi-functional previous
releases we should stop calling it "experimental".  Alternatively,
while we still call it experimental, let's fix it properly and get it
right.

>  Is it a big issue if system_clock will have
> just old resolution (usec) and =auto code is reverted to only tweak
> steady_clock (aka. _GLIBCXX_USE_CLOCK_MONOTONIC) (then for 4.8 the change
> would be just to drop
>           ac_has_clock_realtime=yes
> line from if test x"$ac_has_clock_monotonic_syscall" = x"yes"; then)?

IMHO yes, that's a big issue.  I believe most users are more
interested in system_clock than in steady_clock, and we should provide
a nanosecond-resolution system_clock if the OS supports it.


> Ugh, C++ and ABI doesn't go well together...

Yeah, this stuff's hard.  But I hope we can get a stable ABI for 4.9,
even if it's incompatible with previous releases.


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