New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q: any reason for which date:format(fmt, local_time,...) methods take 'timepoint' by value? #82
Comments
The only rationale that I used was that a However I never measured (before now). I just did an experiment inspecting the optimized assembly of this test:
There were differences, but the differences are likely in the noise level. Some operations were moved from one place to another. Overall, the line count on the assembly listing was 0.29% smaller for the I can't really get excited about one way vs the other. However if you prefer the |
Thanks - all things being equal, I do prefer the I can get around with my own overrides/wrappers which take a |
Ah, on the same line... would you consider++ doubling the number of format functions with date::detail::format(....) { // heaps of work and then at the end... f.put(os, os, os.fill(), &tm, fmt.data(), fmt.data() + fmt.size()); // -----^-- already an ostream return os.str(); } ++ ;) do they call this "cost externalization"? |
I'm not crazy about the idea. But I'll give it some thought. |
The pass by I'm leaving this open for now as I'm still contemplating your suggestions on |
Thanks. The argument in favour of the second is a matter of performance and performance only - the second form breaks the 'fluency' of the l-shift operator std::cout << "Date of birth: " << date::format(fmtstr, tp) << std::endl << "Sex: yes, please" << std::endl ; vs std::cout << "Date of birth:"; date::format(std::cout,fmtstr, tp); std::cout << std::endl << "Sex: yes, please" << std::endl ; But I'd choose the second when performance is required and code fluency is not an issue (e.g. remote services with json interfaces) |
The 2nd form also doesn't respect That being said, your request also induced me to take another look at
which aligns with the current use of |
Closing for now as the primary issue has been addressed. At this time I don't anticipate creating a |
I looked into the code and, half-heartedly, I saw/accepted the reason of passing the
std::string fmt
by value.But why the
tp
(timepoint) parameter is by value and not byconst local_time&
?Assuming one uses
local_time
vars as data-members of other classes/struct, most of the time aformat(fmt, tp)
call will originate in cases in which the parent struct is subject to 'stringification' - e.g.operator << (ostream&, const parent_struct& toDump)
- in which cases, the parent struct will be passed 'by const reference'.Yes, of course, one can create a local copy for that
local_time
data member (with optimisation level high enough, it'll be an operation as cheap as creating and init-ing along
), but it's... I don't know... say, annoyingly opposite with 'output ops traditions'?The text was updated successfully, but these errors were encountered: