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.
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.
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.
> 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.
I'm more happy to see C++ moving to consolidate around a single formatting model.
This past year we were porting Elemental (PC game) to 64-bit so it's pretty old code. There are a gazillion different string types in it (sprintf and beyond).
> 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
> 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.
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.
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.
Surely std::print() shouldn't print anything?
It's a typo, he describes it as std::println in the text, but the code snippet is just print()
Why even call it in that case?
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.
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.
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:
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.> 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.
Yes, if they explicitly call code that appears useless than a warning makes sense. Not if you write a public API that supports it though.
If you write an API you have a responsibility to ensure it cannot be misused. This is very hard.
It's apparently a typo in the article, they probably meant to write `println()`.
I think it is a typo, and should be std::println()
I'm more happy to see C++ moving to consolidate around a single formatting model.
This past year we were porting Elemental (PC game) to 64-bit so it's pretty old code. There are a gazillion different string types in it (sprintf and beyond).
> 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.
...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...).
> 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
Yes, but WTF-8 is not UTF-8.
> 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.
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.
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.