Improvements to Std:Format in C++26

https://mariusbancila.ro/blog/2026/06/19/improvements-to-stdformat-in-c26/

by jandeboevrie • 1 month ago

37 19 1 month ago

mariusbancila.ro

veltas• 30 days ago

Surely std::print() shouldn't print anything?

nikbackm• 30 days ago

Why even call it in that case?

xuhu• 30 days ago

It's apparently a typo in the article, they probably meant to write `println()`.

IshKebab3• 30 days 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.

steeleduncan• 30 days ago

I think it is a typo, and should be std::println()

CamouflagedKiwi• 30 days ago

It's a typo, he describes it as std::println in the text, but the code snippet is just print()

Longhanks• 30 days 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.

...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...).

manwe1502• 30 days ago

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• 29 days ago

Yes, but WTF-8 is not UTF-8.

randusername• 30 days 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• 29 days 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.

arunc• 30 days 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.

draginol• 29 days ago

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).

Improvements to Std:Format in C++26

Related Stories