Where do I forward to ostream?

lazy_string:s main purpose was not originally to just provide a means to do format for streams, but rather make this:
```cpp
std::string str = ...; // initialised by something 
...
str = lazy_format("..."...);
```
as efficient as:
```cpp
str.clear();
format_to(std::back_inserter(str), "..."...);
```
.
When the question for interoperability between new formattable types and old ostreams arrised, I added a second use-case for it. But if that is not desirable, then I can omit it.

// Robin

On Sat, Dec 14, 2024, 17:48 Victor Zverovich via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
> The std::chrono formatters do for empty chrono specs.

The whole formatter specialization is not defined by forwarding to ostream though. Describing a subset of outputs in terms of other APIs is a bit different and just a matter of avoiding duplication in the spec.

- Victor

On Sat, Dec 14, 2024 at 8:01 AM Jonathan Wakely <cxx@kayari.org> wrote:


On Sat, 14 Dec 2024, 15:28 Victor Zverovich via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
I would also add that forwarding to ostream is almost always a bad idea and none of the standard formatters do that for very good reasons

The std::chrono formatters do for empty chrono specs.


(even basic things like padding are incompatible because ostreams don't work with Unicode). It is probably OK as an opt in for quick and dirty debugging code but nothing more than that.

Cheers,
Victor

On Thu, Dec 12, 2024 at 11:49 AM Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

I would be against an automatic adaptors of this nature.

 

Facilities such as std::format and std::basic_ostream are 2 different families of API’s, although their purpose overlap they are fundamentally different things and work under two different philosophies. And I would hope the “std::basic_ostream” family to be completely removed in the future.

 

 

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> On Behalf Of Robin Savonen Söderholm via Std-Proposals
Sent: Thursday, December 12, 2024 2:23 PM
To: std-proposals@lists.isocpp.org
Cc: Robin Savonen Söderholm <robinsavonensoderholm@gmail.com>
Subject: [std-proposals] Format output-streamable types?

 

Hi!

I enjoy the `format`, `format_to` and `print`-facilities that came with C++20 and 23 (coming from the fmt-library) but I just noticed that I can't format e.g. std::bitset. Bitset, however, do have an operator<<() defined which should be usable in the format context. So I made a very basic, proof-of-concept streambuf-derived type that could take an output iterator and wrap it inside streambuf:s API so that it was possible to call the operator<<() with an arbitrary output (char) iterator. I.e. I could do a formatter::format-function that just delegated the work to the operator<<().

I do however, wonder if it is best to just ask for the formatter to be specialised for all types that already have an operator<< (as it may arguably be slightly faster and removes the need of vtable calls inside the format function) or if it actually is desirable to have a default specialisation that says "incase of an operator<<(basic_ostreambuf<Char...>&, T const&) exist, use it for formatting". I could also think of a hybrid version where manual specialisation of std-types are made as well as the iterator-to-stream_buf type that can be used by users that do not want to re-implement their type-to-string logic.

Thoughts?

// Robin

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals