If you use the fmt library it would only require one extra temporary string to be constructed and it works trivially with something like phosphor logging.

log<level::INFO>(fmt::format("My error: {}", filename));

It also has the advantage of understanding basic c++ types like std::strings and std::string_views.

On Mon, Jun 1, 2020 at 8:33 PM 郁雷 <yulei.sh@bytedance.com> wrote:

> ---
> ## Don't require `-o verbose` for systemd journal MESSAGE field context
> The MESSAGE field of a systemd journal entry should be self describing and not
> rely on additional structured log data. For example when the MESSAGE field
> references a filesystem path, the path should appear in the MESSAGE field.
> When the MESSAGE field references a failed system call, the system call and the
> return value should appear in the MESSAGE field. This keeps the journal
> informative and useful for casual journal users. Note that it is perfectly
> acceptible to add (duplicate) structured log entry values for the data that
> appears in MESSAGE. This guideline only prescribes that the data _not_ be
> omitted from the MESSAGE field value.
>

I have a bit concern about this. The existing phosphor-logging API
does not support this well.
Specifically, it does not support the "printf" way to generate a
string with the variables to log.
So previously we typically put the variables in entries.
I do agree that logging the variables in the MESSAGE field is much better.
But to encourage such logging, the logging API should be enhanced to
support the "printf" way.
E.g.
log<level::INFO>("Something is wrong: %s:%d", xx, xxx);
is much better than:
std::string to_log = xxx; // generate the message manually
log<level::INFO>(to_log);

Otherwise, it's really not convenient to write such logging code.