Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Formatting text in C++: Old and new ways

mariusbancila.ro

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Formatting text in C++: Old and new ways

#41

Post by i-use-nixos-btw »

ruph123 wrote: post #40

Will C++ ever get the possibility to just print the contents of an object like Rust does (with the automatic debug trait)? I am tired of writing my own print functions for random objects when debugging because the API developers did not bother to override the <<operator. One of those things that are hard to accept when coming back from Rust.

Not until we get reflection. And reflection efforts seem to be at an impasse, so I don’t imagine we will see it for a few years at least.

I will add, though, that I’ve found copilot to be very handy when it comes to generating formatting. Last week I used it while writing fmt::formatter specialisations for a library with 50 structs, some having over 20 members. Writing all of them took about 10 minutes. I dare say the same would hold for operator<< overloads.

Re: Formatting text in C++: Old and new ways

#42

Post by miohtama »

halayli wrote: post #13
nuancebydefault wrote: post #9

I find it disappointing that cpp20 still doesn't have a solution that is more convenient than good ol printf (except for memory safety). Another example would be convenient list comprehension, convenient maps wihout juggling around with tuples, first(), second(), at()...

What's wrong with std::format?

It does not have enough greater or less signs in the function signature :)

Re: Formatting text in C++: Old and new ways

#43

Post by i-use-nixos-btw »

mkoubaa wrote: post #30
guitarbill wrote: post #3

It seems so trite, especially in 2023, but please don't use sprintf. It isn't safe in general. (Even snprintf is tricky.)

There are a lot of use cases where "isn't safe" is absolutely irrelevant

OTOH, in many of the cases where “isn’t safe” IS relevant, the developer believes it isn’t.

Re: Formatting text in C++: Old and new ways

#44

Post by emmelaich »

f1refly wrote: post #28
nuancebydefault wrote: post #21

Earlier quoted context omitted.

Nothing but (1) notation wise not very different from the old printf which is looked down upon. (2) f"{name}'s hobby is {hobby} " would read like a novel and there a lot less comma seperated arguments. (3) std::format is quite a lot of characters to type for something so ubiquitous.

Typically, you'd just `using namespace std` on top of you file. Afterwards calls to `format` have the exact same length as `printf`.

I know it's not recommended but I use it for main().

And extensive formatting and/or output should be minimised outside main(), imho.

Re: Formatting text in C++: Old and new ways

#45

Post by i-use-nixos-btw »

nuancebydefault wrote: post #21
halayli wrote: post #13

Earlier quoted context omitted.

What's wrong with std::format?

Nothing but (1) notation wise not very different from the old printf which is looked down upon. (2) f"{name}'s hobby is {hobby} " would read like a novel and there a lot less comma seperated arguments. (3) std::format is quite a lot of characters to type for something so ubiquitous.

(2) is a point I firmly agree with (though not everyone does), but it’s a hard one.

Here’s the way I think about it. I don’t think I’m wrong but I’m absolutely open to being told otherwise.

C++ is a language. It has a standard library. The library depends on the language, but the language shouldn’t depend on the library. This is because many applications cannot use the standard library, or parts of it.

The conceptual issue with fstrings in C++ is that the formatting is done on a library level. An fstring would be a language feature. It wouldn’t be reasonable for syntax sugar to resolve to a library call.

So what we’d need is a way of having parameterised strings that the language knows to separate out into parameters in a function call. For instance:

f(f”Hello, {planet}”);

would resolve to:

f(“Hello, {}”, planet);

such that replacing f with std::format, std::print (C++23), fmt::format, fmt::print, spdlog::info, spdlog::error, or even scn::scan (?), would do exactly what you want.

However, the expression f”Hello, {planet}” would be meaningless on its own, and care would need to be taken to avoid:

std::string x = f”Hello, {planet}”;

from resolving to:

std::string x = “Hello, {}”, planet;

Which would be equivalent to

std::string x = planet;

Thanks to C++‘s ludicrous comma operator.

Re: Formatting text in C++: Old and new ways

#46

Post by vvanders »

ruph123 wrote: post #40

Will C++ ever get the possibility to just print the contents of an object like Rust does (with the automatic debug trait)? I am tired of writing my own print functions for random objects when debugging because the API developers did not bother to override the <<operator. One of those things that are hard to accept when coming back from Rust.

The fact that Rust also has a pretty-print("{:#}")[1] a single character away is also really convenient. When you're working with JSON or debug printing types it's nice to be able to format that without reaching for external tools.

[1] https://doc.rust-lang.org/std/fmt/

Re: Formatting text in C++: Old and new ways

#47

Post by cozzyd »

38 wrote: post #8
guitarbill wrote: post #3

It seems so trite, especially in 2023, but please don't use sprintf. It isn't safe in general. (Even snprintf is tricky.)

saying "dont use" something isn't really actionable, unless you give a safe alternative.

asprintf is often a better choice if you're heap allocating anyway. For a static or stack buffer, obviously snprintf, unless you know the maximum possible length won't exceed (which you often do....).

Re: Formatting text in C++: Old and new ways

#48

Post by repsilat »

a_e_k wrote: post #37
lionkor wrote: post #23

Earlier quoted context omitted.

just consider const reference to be the default for non-primitive types

My rule of thumb is to use const references when the sizeof the type is larger than the sizeof a pointer or reference.

Might be worth using values/copies even a bit bigger, so long as it's "simple" data. This[1] short post argues for passing `std::string_view` (~2 pointers) by value, for

- Omitting pointer indirections (loads),

- Not forcing the pointee to have an address (i.e. gotta be in memory, not just registers), and

- Eliminating aliasing questions, potentially leading to better codegen if the function isn't inlined.

1: https://quuxplusone.github.io/blog/2021/11/09/pass-string-vi...

Re: Formatting text in C++: Old and new ways

#49

Post by xmonkee »

logicchains wrote: post #33
nuancebydefault wrote: post #17

Earlier quoted context omitted.

To be honest, if that's the notation, i will not be very eager to jump on cpp23. That said, I admire people who's minds stay open for c++ improvements and make that effort.

Well you could write it as to (items | filter(shouldInclude) | transform(f)) if you really want to, but generally C++ programmers prefer to be explicit and include the namespaces.

>but generally C++ programmers prefer to be explicit and include the namespaces.

why, though? Collisions in the stdlib? stdlib is too new to not be the default for these names?

Post reply on HN