Consider printfln() convenience function

[c42f]

I'm considering adding a printfln() function for convenience which simply appends a "\n" to the usual printf() output. This would be especially useful for ad hoc debug logging. Naming wise, this is consistent with some other languages such as D which has writef/writefln. No obvious precedent in the C and C++ world come to mind.

On the downside, it's a new public API for something that's trivial to do with plain old printf("foo\n"), but sometimes I still forget the newline, especially when using alongside a logging API which appends newlines automatically.

There's a small but nonzero number of people watching tinyformat - thoughts anyone?

[parnham]

I don't see the harm, since it wouldn't affect any existing API calls.

We use tinyformat throughout our open-source and internal projects where output is usually done via our logger (to syslog/file/cout) so newlines are handled automatically, everything else tends to use the tfm::format function for std::string formatting. Therefore it would be of little use to us, but might be handy for others especially those coming from other languages, for example C# which has Console.Write and Console.WriteLine.

[c42f]

Thanks for the reply @parnham - it's good to know your usecase. I think this mainly comes down to a question of utility vs bloat. The use case for me would be in adhoc debugging where I want to bypass the logger, or basic logging when I don't have a proper logger available.

(By the way, I noticed that your FLOG() macro doesn't benefit from the early bailout in LOG() so you'll wear the cost of calling tfm::format() - including at least one allocation - regardless of whether you see the message or not. This could be inefficient if you do a lot of debug logging where you'll end up formatting the messages, only to throw them away at normal log levels.)

[parnham]

Good to avoid unnecessary bloat, so it really depends on whether there is further demand for that functionality.

As far as I was aware the macros would all be expanded by the compiler so even the FLOG should expand to

    { if (v > logger::instance().verbosity); else logger::instance().log(v, __PRETTY_FUNCTION__, tfm::format(message, __VA_ARGS__)); }

unless I'm missing something about how macros are combined?

[c42f]

Eh silly me, you're quite correct. I've generally used inline functions to achive part of what you're doing with the macros there which tripped me up.

[kainjow]

I see no harm in adding it.

[c42f]

Well, I checked the compile times with make bloat_test and there doesn't really seem to be a compile time hit for adding this (at least with gcc), so I did (see 8c9cb36).