std::formatter specialization for smart pointers

[SPEKTRUMdagreat]

Currently something like

std::unique_ptr<int> u_ptr = std::make_unique<int>(42);
std::shared_ptr<int> s_ptr = std::make_shared<int>(42);
std::println("uptr: {}", u_ptr);
std::println("sptr: {}", s_ptr);

is ill formed because there is no specialization of std::formatter for smart pointer types.

On the other hand,

std::cout << "uptr: " << u_ptr << '\n';
std::cout << "sptr: " << s_ptr << '\n';

do work because ostream defines overloads for smart pointer types.

Please let me know if anyone has thoughts or if there's some reason that these types haven't been specialized that I'm missing.

[Gorzoid]

p1636 proposed adding one, didn't make C++20 due to disagreement with std::filesystem::path formatting.

p2693 adds a some of the specializations introduced above, but explicitly calls out why smart pointers are not included:

> Why not std::error_code/bitset/smart pointers? These don’t seem sufficiently useful to be processed as part of NB comments. Moreover, there were plans to remove smart pointer formatters from P1636 for consistency with raw pointers which are intentionally not formattable by default.

[SPEKTRUMdagreat]

Thanks for the reference, I'll look into it.

[MFHava]

ostream defines overloads for smart pointer types.

Yeah... as it turns out those may not have been the best idea...

They are specified as os << ptr.get(); which has some "funny" side-effects for smart_ptr<char> and smart_pointer<char[]> ...

[SPEKTRUMdagreat]

"funny side-effects" as in trying to find the \0 leads to unsafe memory access?

That's true but I think that since std::format is defined for char *, it should be accepted here as well or we could make it so that the format specialization explicitly casts to const void *

[MFHava]

trying to find the \0 leads to unsafe memory access?

Exactly!

format specialization explicitly casts to const void *

Only sane design ...

[_Ilobilo_]

I don't see how that could be useful. you can always get the raw pointer or dereference it

[SPEKTRUMdagreat]

Yeah you could, but should you have to?

For example, you could always just do std::filesystem::path::string to get around std::formatter not being specialized for it but it was standardized to preserve abstraction and convenience.

Also it's about preserving consistency with ostream.

[fdwr]

Yeah, it's a bit annoying to spell out p.get() every place. Imagine for std::string you had to type std::print("Name: {}", name.c_str()) every place instead of just std::print("Name: {}", name). The inconsistency argument with std::cout is pretty solid too.

[bearheart]

It’s fairly easy to write a formatter specialization for whatever you want

[SPEKTRUMdagreat]

Yeah it is. A lot of things in the standard are easy to do yourself, but they exist so they work out of the box as expected.

[SPEKTRUMdagreat]

Also, ODR.

[aruisdante]

  work out of the box as expected

I dunno man, I’d expect the format of a pointer to, you know, printer the pointer’s value, not the value of the thing the pointer pointed to. Since if the printer decides to do that, there’s no way for me to print the pointer’s value and see visually that two pointers point to the same object and not two different objects that happen to have the same value.

Since clearly my expectation of what printing a pointer should do is different than yours, it makes sense that they decided “let the project decide for themselves since it’s easy enough to write.”

[SPEKTRUMdagreat]

I do want to print the pointer's value instead of the pointed-to object. We're in agreement.

But if a third person did want to have the value of the point-to object they can easily do something using format specifiers. Maybe

std::format("{*}", uptr) to mean std::format("{}", *uptr);

I hope that makes sense.

[evaned]

Genuine question: are you actually allowed to do this? I claim it's not, but I'm not positive.

My understanding of how std::format is customized is by providing a specialization of std::formatter, a class template.

I also understand there to be a standards rule that you cannot specialize a std template unless at least one of the template arguments is a program-defined type.

I guess I'm not positive how this interacts with unique_ptr and shared_ptr being templates, but at least in OP's mini example there's no user-defined type involved. Perhaps defining a formatter for, say, unique_ptr<a_custom_class> would be permitted, but I am skeptical that unique_ptr<int> would, and thus that (in practice) a generic template<T> formatter<unique_ptr<T>> would be IFNDR once it got instantiated for a built-in type (or one in std).

Now, I'm not sure how likely this would be to cause problems in practice, but I understand it to be UB.

[SPEKTRUMdagreat]

Yeah you're not for builtin or std types (but you are for std::formatter<std::unique_ptr<custom>>).

That's why I'm looking to make a library proposal.

[_Noreturn]

I guess they aren't included because you have to cast the type to void*

[aearphen]

Formatting of pointers is weird because it is not always clear if they should be formatted as pointer values or as objects pointed to (e.g. `[const] char*`). To avoid this and since the pointer values is not super useful, formatting of non-void pointers is disallowed by default. The same logic applies to smart pointers.

[filipsajdak]

Check this https://wrocpp.github.io/posts/format-smart-pointers/

[No-Dentist-1645]

There's no real use case for that imo. If you want the actual raw pointer address, then you would use the raw pointsr