惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

腾讯CDC
Microsoft Azure Blog
Microsoft Azure Blog
B
Blog
S
SegmentFault 最新的问题
WordPress大学
WordPress大学
P
Proofpoint News Feed
Hugging Face - Blog
Hugging Face - Blog
MyScale Blog
MyScale Blog
A
About on SuperTechFans
雷峰网
雷峰网
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
T
The Blog of Author Tim Ferriss
MongoDB | Blog
MongoDB | Blog
博客园 - 【当耐特】
The Cloudflare Blog
F
Fortinet All Blogs
小众软件
小众软件
博客园 - 三生石上(FineUI控件)
宝玉的分享
宝玉的分享
罗磊的独立博客
量子位
有赞技术团队
有赞技术团队
V
V2EX
Engineering at Meta
Engineering at Meta

Lobsters

CIFSwitch: a non-universal Linux local root vulnerability RIPE NCC session fixation: poaching logins with an Atlas probe GNOME 2.20 but its Web Components Agentic Search for Context Engineering – Leonie Monigatti Garnix is shutting down [not OC] akashina.tngl.sh/jjc Concerning Emacs (and Jazz) Nitpicking the shell history scene in ‘Tron: Legacy’ What's cooking on SourceHut? Q2 2026 The tenth OpenPGP email summit Package managers that package package managers Clojure on Fennel part three: parsing WordPress at 23 Finding Miscompiles for Fun, Not Profit GitHub - creusot-rs/creusot: Creusot helps you prove your Rust code is correct. Announcing Rust 1.96.0 | Rust Blog A Love Letter to Neovim sqlite AGENTS.md Am I a Bad Friend? CSS vs. JavaScript • Josh W. Comeau Erlang Ecosystem Foundation - Supporting the BEAM community A brief note about slot access cost in Common Lisp Keyboard latency probe Rethinking the GNOME clipboard issues Back to the Building Blocks’ Building Blocks Tech Notes: Theseus: translating win32 to wasm Fast is better than slow Content-addressed Rust builds (or, what kache actually caches) Intent to Prototype: Embedding API Canada’s Bill C-22 and the security cost of collecting more data
Improvements to std::format in C++26
Marius Bancila · 2026-06-21 · via Lobsters

The C++26 standard features a series of improvements to the format library. In this article, we will look at the most important of them.

Printing an empty line

Prior to C++26, printing an empty line had to be done like this:

std::print("\n");

In C++26, std::println has an overload without any parameters that prints a new line to the console.

std::print();

Formatting pointers

Formatting pointer types was not available directly, it required a hack: reinterpreting the pointer type as an integer type in order to print it.

int i = 0;
const void* p = &i;

std::println("{:#018x}", reinterpret_cast<uintptr_t>(p));

In C++26, the formatting library supports formatting of pointer types directly:

  • implicitly, no specifier is required
  • explicitly, with wither the p (for lowercase) or P (for uppercase) specifiers

Null pointers are formatted as 0x0 (unless padding is specified).

Here are several examples of formatting pointers:

int i = 0;
const void* p = &i;
    
std::println("{}",     p);       // lowercase, the default           => 0x7fffb2715a54
std::println("{:p}",   p);       // explicit, same as none           => 0x7fffb2715a54
std::println("{:P}",   p);       // uppercase                        => 0X7FFFB2715A54
std::println("{:018}", p);       // zero-padded to width 18          => 0x00007fffb2715a54
std::println("{:>20}", p);       // right-aligned in a 20-wide field =>       0x7fffb2715a54
std::println("{}", nullptr);     //                                  => 0x0
std::println("{:016}", nullptr); //                                  => 0x00000000000000

Formatting paths

Another feature that required a workaround was printing paths from the std::filesystem namespace. You could use path::string() to get the string representation of a path.

namespace fs = std::filesystem;

fs::path p = "/usr/local/bin/clang++";
std::println("{}", p.string());

However, this prints the path unquoted. On the other hand, using the << operator would print the path in quotes:

std::cout << p << '\n';

C++26 adds a std::formatter for std::filesystem::path, which makes it easier to format paths.

  • by default, paths are formatted unquoted
  • the ? option defines a debug form which gives an escaped representation (in quotes)
  • the g option forces generic (forward-slash) separators (which mainly shows up on Windows)
fs::path p = "/usr/local/bin/clang++";
std::println("{}",  p);   // /usr/local/bin/clang++
std::println("{:?}", p);  // "/usr/local/bin/clang++"
fs::path p = R"(C:\Users\marius\file.txt)";
std::println("{}",    w);  // C:\Users\marius\file.txt    (native separators)
std::println("{:g}",  w);  // C:/Users/marius/file.txt    (generic)
std::println("{:g?}", w);  // "C:/Users/marius/file.txt"  (generic + escaped)

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 {:?}.

constexpr std::format

In C++26, the formatting functions std::format, std::vformat, std::format_to, std::format_to_n, std::formatted_size, and their wide variants, plus the underlying pieces (the format context, std::basic_format_arg, std::basic_format_string, and the format member of the standard formatters) are constexpr.

This makes it possible to use static_assert for instance with std::format such as in the following examples:

static_assert(std::format("{} {}", 1, 2) == "1 2");

static_assert(sizeof(void*) == 8,
              std::format("expected 64-bit, pointer is {} bytes", sizeof(void*)));

This works because it relies on to_chars() overloads which have been made constexpr, but only for integral types. So it can be used with strings, integer types, bool, char, and pointers. But there are several limitations to this feature. The following are not supported:

  • floating-point types
  • chrono types
  • locale-aware formatting (using the L specifier – as in {:L}, makes the call non-constant)

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.

std::runtime_format becomes std::dynamic_format

The format string of std::format or std::print must be a constant expression. For instance, you can write this:

std::println("{} = {}", "x", 13);

But you cannot write the following:

std::string strf = "{} = {}";
std::println(strf, "x", 13);

This is ill-formed because strf is only known at runtime, and therefore is not a constant expression. The workaround is to use std::vformat:

const char* key = "y";
int val = 13;
std::string strf = "{} = {}";

std::string s = std::vformat(strf, std::make_format_args(key, val));
std::println("{}", s);

There is a workaround for the workaround (it’s basically syntactic sugar for std::vformat), the formally known as std::runtime_format function, that returns an object that stores a dynamic format string directly usable in user-oriented formatting functions and can be implicitly converted to std::basic_format_string.

std::string strf = "{} = {}";
std::println(std::runtime_format(strf), "x", 13);

In the final version of C++26, this has been simply renamed to std::dynamic_format (although at this time the compilers that do support it still use the previous name). Therefore, the snippet above now becomes:

std::string strf = "{} = {}";
std::println(std::dynamic_format(strf), "x", 13);

std::dynamic_format is constexpr, which means it can be used in constant-evaluation contexts, such as in the following example:

constexpr auto make_string = [](std::string_view f) {
    return std::format(std::dynamic_format(f), 1, 2);
};
static_assert(make_string("{}+{}") == "1+2");

See more

You can learn more about these changes from the following articles: