Rendered at 12:41:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
randusername 1 hours ago [-]
> This makes it possible to use static_assert for instance with std::format...
This is great but it sounds like it doesn't work for floats yet
> For now, compile-time std::format covers integers, strings, and diagnostics well, with floating-point support waiting on a separate paper (P3652) to make the floating-point <charconv> functions constexpr.
leni536 33 minutes ago [-]
I am working on it. Floating-point IO is rather heavyweight, so the usual approach of naively slapping constexpr on all the things and putting them in headers can have some observable negative consequences on resource usage during compilation even if you don't use the new constexpr functionality.
To the best of my knowledge fmtlib does implement constexpr formatting for float and double, but not long double.
veltas 5 hours ago [-]
Surely std::print() shouldn't print anything?
CamouflagedKiwi 4 hours ago [-]
It's a typo, he describes it as std::println in the text, but the code snippet is just print()
nikbackm 5 hours ago [-]
Why even call it in that case?
xuhu 5 hours ago [-]
It's apparently a typo in the article, they probably meant to write `println()`.
IshKebab 3 hours ago [-]
Typo in this case, but in general supporting "useless" code like this is sometimes a good idea because it makes writing generic code easier. Maybe not in this case.
bluGill 1 hours ago [-]
The counter is useless code often is a sign of a bug. Possibly someone started implementing something and then failed to finish it. I often want my compiler to warn on useless code.
IshKebab 37 minutes ago [-]
No, I mean the API should support "useless" code where it makes sense, not that you should manually write it. I don't actually think it applies in this case, but just as a general principle.
A classic example of where they didn't do this right is SystemVerilog arrays. You cannot have busses with zero wires in them. "Why would you need that?" somebody probably said... What's the point of a bus with no wires? Well imagine you write a SystemVerilog module with some memory interface like this:
module foo (
input var logic [31:0] i_addr,
input var logic [7:0] i_data,
input var logic [3:0] i_user_data,
...
But now you want to make it generic. No problem!
module foo #(
parameter A = 32,
parameter D = 8,
parameter U = 4
) (
input var logic [(A-1):0] i_addr,
input var logic [(D-1):0] i_data,
input var logic [(U-1):0] i_user_data,
Now suppose you don't have any user data. You set U=0, but that gives `logic [-1:0]` which is invalid because they made the incorrect decision to use closed interval syntax. In fairness Verilog is very old so maybe it wasn't so obvious back then that you always use 0-based indexing with right-open intervals.
bluGill 10 minutes ago [-]
> I mean the API should support "useless" code where it makes sense, not that you should manually write it.
There is the conflict - if I write useless code I want the compiler to stop me. This is very different from generic code where sometimes a part simplifies to useless code in some particular context even though the whole is useful. Anytime the system can tell the difference between these two I want them treated different.
Telling the difference between useless code and generic code that has a useless form in this context is often not a solvable problem. There are also cases where if we had known better 40 years ago we would have made a different choice, but it is too late now. However I think the rules stands: the system should reject useless code when that is what someone writes even if the code otherwise parses correctly.
steeleduncan 4 hours ago [-]
I think it is a typo, and should be std::println()
Longhanks 4 hours ago [-]
> A related issue solved along was Windows string representation of paths. std::filesystem::path stores its text in wchar_t encoded as UTF-16 (Windows native). But p.string() narrows it down to the active code page, rather than UTF-8 which is what the formatting library expects. The result was a non-ASCII path could get transcoded to gibberish. The C++26 std::formatter<std::filesystem::path> converts Windows native UTC-16 to UTF-8 using Unicode transcoding and avoiding code pages, therefore solving the problem.
> Ill-formed UTF-16 is replaced with U+FFFD by default, or escaped under {:?}.
Silently corrupting the path seems an odd choice in this day and age, when WTF8 has existed for many years and fixes this round trip bug / security vulnerability
silon42 32 minutes ago [-]
Yes, but WTF-8 is not UTF-8.
arunc 1 hours ago [-]
Articles with code examples that doesn't show their output are just silly. This one deals with `std::println` to print pointer formatting with no output.
This is great but it sounds like it doesn't work for floats yet
> For now, compile-time std::format covers integers, strings, and diagnostics well, with floating-point support waiting on a separate paper (P3652) to make the floating-point <charconv> functions constexpr.
To the best of my knowledge fmtlib does implement constexpr formatting for float and double, but not long double.
A classic example of where they didn't do this right is SystemVerilog arrays. You cannot have busses with zero wires in them. "Why would you need that?" somebody probably said... What's the point of a bus with no wires? Well imagine you write a SystemVerilog module with some memory interface like this:
But now you want to make it generic. No problem! Now suppose you don't have any user data. You set U=0, but that gives `logic [-1:0]` which is invalid because they made the incorrect decision to use closed interval syntax. In fairness Verilog is very old so maybe it wasn't so obvious back then that you always use 0-based indexing with right-open intervals.There is the conflict - if I write useless code I want the compiler to stop me. This is very different from generic code where sometimes a part simplifies to useless code in some particular context even though the whole is useful. Anytime the system can tell the difference between these two I want them treated different.
Telling the difference between useless code and generic code that has a useless form in this context is often not a solvable problem. There are also cases where if we had known better 40 years ago we would have made a different choice, but it is too late now. However I think the rules stands: the system should reject useless code when that is what someone writes even if the code otherwise parses correctly.
...only to then convert it back to UTF-16 for WriteConsoleW(), which std::print() usually calls (unless not running in a console) (https://github.com/microsoft/STL/blob/488e7953685722d2d6666f...).
Silently corrupting the path seems an odd choice in this day and age, when WTF8 has existed for many years and fixes this round trip bug / security vulnerability