Live data from Hacker News

Formatting text in C++: Old and new ways

mariusbancila.ro

21–30 of 73 posts

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

#21
post #13

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?

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.

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

#22

Earlier quoted context omitted.

Maps have been improved quite a bit. For example, if you have a std::map , you can iterate over it like this: for (auto [s, n]: my_map) { // s = string key, n = int value } You can test for membership: if (my_map.contains(“foo”)) { /* do something * } Although I still usually use find because if the key is in the map, I probably want the value. You can use initialization lists with them too: std::map my_map = { { “on…

for (auto [s, n]: my_map) copies all the data needlessly, better to use for (const auto& [s, n]: my_map)

That's why some newer languages have 'const are the default'.

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

#23

Earlier quoted context omitted.

for (auto [s, n]: my_map) copies all the data needlessly, better to use for (const auto& [s, n]: my_map)

what a language

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

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

#24

Earlier quoted context omitted.

for (auto [s, n]: my_map) copies all the data needlessly, better to use for (const auto& [s, n]: my_map)

That's why some newer languages have 'const are the default'.

I'm pretty sure it's the reference that makes the data not be copied.

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

#25

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

For list comprehension, we have (C++23): `std::ranges::to (items | std::views::filter(shouldInclude) | std::views::transform(f))` it’s not quite `[f(x) for x in items if shouldInclude(x)]` but it’s the same idea.

Sweet baby Jesus I thought that was a joke as I started reading it. Still not entirely sure.

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

#27
post #8

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.

The safe alternatives are in the article.

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

#28
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.

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

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

#29
finally!

I remember using variadic templates to print things in a single function call, like this:

    int i; float f; string s;
    print_special(i, f, s);
It would somehow imitate the behavior of python's print()

I never really understood how variadic template worked, maybe one day I will, and to be honest, I'm suspecting it's really not very kind to compile time, it's a lot of type checks done under the hood.

It's a bit problematic that C++ cannot be compiled quickly without a fast CPU, I wonder how this is going to be addressed one day, because it seems that modules aren't a good solution to that, yet.

Post reply on HN