On Thu, 4 May 2023, 05:18 Simon Hill, <protogrammer_at_[hidden]> wrote:

> > Is it actually truncated elsewhere, or is the resolution just in seconds
> anyway?
>
> Of my five examples, only the XFCE clock did not have sub-second format
> codes. The others all featured milliseconds, microseconds, and/or
> nanoseconds.
> Every example (other than C++'s std::chrono) I've seen where the time type
> is sub-second, the seconds formatter is still integer-truncated. I just
> looked at a few more, eg QT (
> https://doc.qt.io/qt-6/qml-qtqml-qt.html#formatDateTime-method), which
> continue this pattern.
> GNOME clock (via GLib) even references strftime() but still has sub-second
> codes and truncated-integer seconds.
>

OK, you should definitely add that to the proposal then. That wasn't clear
at all, and makes a much stronger case.


>
>
> > Unheard of, I think.
> Any type that: [internally stores seconds and subseconds in different
> member integers] and [whose "seconds" integer is of a different type than
> that returned from floor<seconds>(t)] would count. This includes <time.h>'s
> "tm" type. If you wanted to implement a format-capable 'clock' wrapper
> struct for "tm" you'd have an example. But still unlikely and not important.
>
>
>
> > And not all time points and durations come from clocks anyway.
> Formatting of chrono types isn't just for formatting values that come
> straight from clocks.
>
> Part of my issue related to file timestamps. Another part was creating
> directories to sort files based on arbitrary timestamp format, which could
> theoretically end up creating a directory for every used nanosecond if the
> clock's precision changed.
>
>
>
> > > That's a good point. And "%t"s already used (why? isn't \t sufficient?
> (same for \n vs "%n"))
>
> > Because strftime supports them.
>
> I see. IMHO it's unfortunate how many C++ design decisions seem based on
> legacy issues.
> Also, Isn't that just the same consistency argument I'm making? A:
> strftime uses %t=tab. B: most software on earth AFAICT uses
> truncated-integer seconds (mostly via %S).
>

>
>
> > I don't read Howard's SO comment as particularly supportive of the idea,
> but maybe I'm wrong. Providing a link explaining how to submit a proposal
> is not necessarily support for the proposal :-)
>
> I agree. I probably shouldn't have worded it like that.
>
>
>
> > The work to implement it is not the issue here. It makes the chrono
> formatter code (slightly) larger and slower, for every call to std::format,
> even for users who don't need the new feature. I'm not sure it's worth it,
> when you can already do it using a cast. Your mileage may vary.
>
> There's constexpr-cleverness going on in the format-string evaluation, so
> the generated binary code shouldn't (given a decent compiler and well
> written header code) be any larger or slower for users who don't use "%s",
> nor should the runtime libraries be affected. You can see this by the fact
> an invalid format string fails at compile time instead of runtime, that you
> can't pass a non-constexpr format string, and that the changes only need be
> made in a header with no runtime library rebuild.
>

I know, I wrote the GCC implementation you're using :-)


> I just compiled a test (via GCC, using "%S" but not "%s") on both my
> patched and non-patched chrono_io.h, and the output binaries are (according
> to diff -s) 100% identical.
>

That's not what I see. Comparing the assembly output for a simple function
that doesn't use %s and formats a compile-time constant, I see that the
assembly code generated by GCC is larger when the unused %s support is
present in the header. I expected to see a difference for formatting a
runtime function parameter, but I even see a difference when formatting a
constant. I might have messed up the test though.



>
> It does, however, use up a valuble conversion specifier character. But I'd
> argue that that applies more to "%t" and "%n".
> It also might slow down compilation by a few negligible nanoseconds.
>
>
>
> > Lastly, is there any hope for a proposal to add the ^^ operator?
>
> This would be a far more important proposal. I don't know if it's been
> proposed before (there's plenty of discussion about it, but I didn't find a
> proposal), but it would require a lot more work to implement, from
> preprocessors to parsers to optimizers. But the permanent effects are only
> positive AFAICImagine.
>
> Should I write it?
>

That should be a separate thread, and I only have an opinion on the library
proposal for std::format.