C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Modularized logging library - prevent parameter evaluation before calling

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Wed, 28 Oct 2026 11:59:01 +0100
I think a language facility we have to let the target function decide, whether to evaluate an expression, are lambdas (and any other forms of callbacks), and those should be mentioned in the discussion here. They can be fully optimized by the compiler as any other construct and are (unoptimized) compatible with different translation units. Even the unoptimized version just has more size, but doesn't do the call, if logging is turned off at runtime. If it is turned on, just the inlining is missing from optimization (without lambdas, the caller would/could inline the evaluation). The mentioned P0927R2 proposal paper about lazy evaluation was last updated in 2019.   -----Ursprüngliche Nachricht----- Von:Rainer Deyke via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 28.10.2026 10:37 Betreff:Re: [std-proposals] Modularized logging library - prevent parameter evaluation before calling An:std-proposals_at_[hidden]; CC:Rainer Deyke <rainerd_at_[hidden]>; On 10/28/26 10:00, Alexander Christensen via Std-Proposals wrote: > Hi, > > Someone reminded me of my erroneous logging function: > LogWarn("Invalid Value {}", GetValue()); > > The function is defined like this: > template<typename... Ts> > void LogWarn(std::string_view fmt, Ts&&... args) > { > #if defined(LOG_WARN) >      // log... > #endif > } You can do this by making LogWarn a macro.  You *should* do this by making LogWarn a macro. One guarantee in C++ is that given functions f and g in the code f(g()), function f cannot prevent g from being called or affect the evaluation of g() in any way.  It's a tradeoff that makes code easier to understand at the cost of limiting the expressive power of the language.  And there already is an escape hatch: turn f into a macro, and the guarantee goes away. You are proposing a second escape hatch, presumably because you don't like macros.  I don't think that's a good enough reason. In some other languages, given the equivalent of f(g()), the function f can control when and if g() is evaluated.  And that's fine for those languages.  It comes at a significant cost in conceptual complexity, but it allows these languages to simplify in other ways (such as by turning flow control structures into regular functions).  But C++ doesn't have to, and shouldn't, imitate them. -- Rainer Deyke - rainerd_at_[hidden] -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2026-10-28 11:00:01