3 ms·

What's wrong with std::format?

nuancebydefault 3y ago
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.
- f1refly 3y ago
  Typically, you'd just `using namespace std` on top of you file. Afterwards calls to `format` have the exact same length as `printf`.
  - nuancebydefault 3y ago
    I don't understand. I genuinely thought that using using namespace std is considered bad practice because of possible arising conflicts. Also you still need to write the word format (though you could alias it to one character, with same namespace conflict possibilities). Am i pedantic?
  - Quekid5 3y ago
    This is questionable advice. In header files 'using namespace' should never be used, in implementation files it opens up some weird edge cases. Instead, do using fmt = std::format and then use fmt(...) as the function call. ... at least that the current advice AIUI.
  - gavinray 3y ago
    This is not widely considered a good practice, please don't "using namespace std".
  - emmelaich 3y ago
    I know it's not recommended but I use it for main(). And extensive formatting and/or output should be minimised outside main(), imho.
- i-use-nixos-btw 3y ago
  (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.
  - iudqnolq 3y ago
    There's precedent for that in JavaScript's format strings. It also allows for cute ideas, like passing the template to a function that does SQL.
  - nuancebydefault 3y ago
    I understand what you are saying. I wonder/doubt if the comma would have to be an explicit step as part of the hand over to the std lib. The comma is a separator that the programmer would use, but does the compiler need that? The compiler needs to translate 1 argument to multiple arguments of multiple types, such that stdlib can receive all info. (The original fstring indeed cannot be expanded by the lib itself, since that would give stdlib a special status). So the needed language feature is a one to multi args translation, where at compile time all types are known. That would mean that in the context of an assignment (in stead of a function argument), the f string does not make sense. In that case the compilation can simply fail, no? I guess the handing over the multiple args of different types is a problem. Not all infinite combinations can be solved by templating and I guess even if it could, the header would contain too much logic since the template expansion needs to happen from the header?
miohtama 3y ago
It does not have enough greater or less signs in the function signature :)

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.

f1refly 3y ago
Typically, you'd just `using namespace std` on top of you file. Afterwards calls to `format` have the exact same length as `printf`.
- nuancebydefault 3y ago
  I don't understand. I genuinely thought that using using namespace std is considered bad practice because of possible arising conflicts. Also you still need to write the word format (though you could alias it to one character, with same namespace conflict possibilities). Am i pedantic?
- Quekid5 3y ago
  This is questionable advice. In header files 'using namespace' should never be used, in implementation files it opens up some weird edge cases. Instead, do using fmt = std::format and then use fmt(...) as the function call. ... at least that the current advice AIUI.
- gavinray 3y ago
  This is not widely considered a good practice, please don't "using namespace std".
- emmelaich 3y ago
  I know it's not recommended but I use it for main(). And extensive formatting and/or output should be minimised outside main(), imho.
i-use-nixos-btw 3y ago
(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.
- iudqnolq 3y ago
  There's precedent for that in JavaScript's format strings. It also allows for cute ideas, like passing the template to a function that does SQL.
- nuancebydefault 3y ago
  I understand what you are saying. I wonder/doubt if the comma would have to be an explicit step as part of the hand over to the std lib. The comma is a separator that the programmer would use, but does the compiler need that? The compiler needs to translate 1 argument to multiple arguments of multiple types, such that stdlib can receive all info. (The original fstring indeed cannot be expanded by the lib itself, since that would give stdlib a special status). So the needed language feature is a one to multi args translation, where at compile time all types are known. That would mean that in the context of an assignment (in stead of a function argument), the f string does not make sense. In that case the compilation can simply fail, no? I guess the handing over the multiple args of different types is a problem. Not all infinite combinations can be solved by templating and I guess even if it could, the header would contain too much logic since the template expansion needs to happen from the header?

miohtama 3y ago

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