puts

[ghost]

If this is supported:

tfm::printf("%s", 9);

might as well support this too:

tfm::puts(9);

http://pubs.opengroup.org/onlinepubs/9699919799/functions/puts.html

[c42f]

I'm not sure this is really worth having; does it add anything over the standard alternative of std::cout << 9;?

[ghost]

newline

[c42f]

Ok fair enough — a newline. I can see the attraction of having something extremely short for quickly dumping a value to stdout. Though if your motivation is for super short syntax, the namespace prefix seems unfortunate. (And without the namespace it looks too much like the C function of the same name.)

Perhaps it would be better for you to define it yourself and use it without the namespace prefix. Then you could have put(9);.

(Note that tinyformat also has tfm::printfln() though in hindsight that might also have been a questionable addition. I thought it would be useful at the time, but in practice I've basically never used it.)

[ghost]

@c42f I dont mind using the existing function, but i dont like the syntax. currently its:

tfm::printf("%s", 9);

which is valid, but its strange because 9 is not a string. I would much prefer syntax like this:

#include <fmt/format.h>
main() {
   fmt::print("{}\n", 9);
}

but i have issue with that project too as newline is not included either. the rust syntax is ideal:

fn main() {
   println!("{}", 9);
}

or Python:

print('{}'.format(9))

[eliaskosunen]

puts stands for PUT String, so it shouldn't be the name of a function not taking a string.

[c42f]

puts stands for PUT String

Yes. This is why I suggested put could be defined [Edit: to be clear — outside tinyformat]. Though actually we should just call it println().

@cup I sympathize that printf with %s isn't the most pleasing for non-strings. But the guiding principle of tinyformat is that it be a viable drop-in replacement for C99/posix printf, warts and all. This means that I will not be designing or implementing any other format specification. Not because it's a bad idea, but because other people have already done a good job of that!

I think we could possibly have generic tfm::println(x). Though again, that's straying away from the mission which is just to do printf properly in C++ with the smallest amount of code, not define any extra APIs...