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] | |
On 05/22/2013 01:49 PM, Jonathan Wakely wrote:
If I understand correctly Jakub's idea, nothing would change from the user point of view in the headers, using now would be still a no-no if the real facility isn't implemented. It would be only a run-time fall back for the situation I mentioned before: the binary is built with headers providing a good clock and then moved to another machine, and dynamically linked to a library which doesn't and then run. We could also spill a warning, at run-time.On 22 May 2013 12:15, Jakub Jelinek wrote:If now() can be perhaps with worse precision emulated in configurations not built against glibc 2.17, perhaps best solution would be to add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to 3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility alias to that.The problem for steady_clock::now() isn't one of precision, it's that it isn't steady if we don't use the monotonic clock. We could define a non-steady steady_clock (with the same precision as system_clock) but is that helpful to users? If that's what we want then yes, we can do the symbol versioning you suggest.
That kind of solution would be definitely Ok with me. Paolo.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |