5 ms·
I kinda like it, it's comfortable and pragmatic. I don't have to look at the docs to figure out what's the format specifier for something like a size_t, and you
by dale_glass 3y ago
I kinda like it, it's comfortable and pragmatic. I don't have to look at the docs to figure out what's the format specifier for something like a size_t, and you can easily add support for whatever might be needed, so you can comfortably do:
std::cout << "Player is at" << _player_pos;
And get the x/y/z breakdown automatically.
- diath 3y agoBut you can do that with fmtlib/std::format as well when you provide formatting for custom types, that just becomes: fmt::println("Player is at {}", _player_pos);
- petters 3y agoShould be possible to implement cout more effectively since there is no string parsing. I say “should” because in practice it seems to be the other way around. I don’t know why.
- hermitdev 3y agoBeen a while since I've looked at it, but pretty sure std::format validates and parses most (all?) format strings at compile time. There should be no runtime penalty.
- vitaut 3y agoThere are some fundamental reasons why cout is slower than stdio/{fmt}: https://stackoverflow.com/a/65325727/471164 https://stackoverflow.com/a/65325727/471164.
- blacklion 3y agoAnd now try to do task which should be as trivial as add 1 format character: output number in hexadecimal and leave stream in same state that was before your code. It becomes cumbersome very fast.