For example I've got following code:

auto z = [](int x) -> int {
    if (x > 0) {
        switch (x) {
            case 2: return 5;
            case 3: return 6;
            default: return 1;
    return 0;

And later I call this several times. In asm code I see external calls with lambda....something... It's becoming not easy to read and I think it also can cause performance. So maybe I win in meta-programming but do I lose in asm debugging and performance? Should I avoid modern language features, macros and other meta programming aspects to be sure in performance and debugging simplicity?

  • 1
    Depending on the version of compiler and its bundled standard library, lambda may indeed be implemented inefficiently. See this question on Stackoverflow. However, the responsibility for improvement should lie on the compiler vendor.
    – rwong
    Jul 8, 2013 at 6:19
  • 18
    You shouldn't need to debug assembly code, unless you are in performances critical path. Also, "clean code" != "good performances". Jul 8, 2013 at 7:41
  • 1
    Fix your indentation please. I tried to do it, but it seems you can't edit just whitespace. Jul 8, 2013 at 8:51
  • 1
    For you, maybe. But your way is nonstandard, and for me it was confusing and took me far longer to read the code than necessary. Write code for other programmers, not for yourself. Jul 8, 2013 at 10:38
  • 4
    @Heather: You appear to be using Ratliff style, which i've never seen before and find hard to read. It's certainly one of the lesser known ones. My impression was that you hadn't indented properly. Nevermind then if you find it readable, i just disagree. Jul 8, 2013 at 12:23

3 Answers 3


Must I think about compiled machine code when I write my code?

No, not when you write your code the first time and don't suffer from any real, measurable performance problems. For most tasks, this is the standard case. Thinking too early about optimization is called "premature optimization", and there are good reasons why D. Knuth called that "the root of all evil".

Yes, when you measure a real, provable performance bottleneck, and you identify that specific lambda construct as the root cause. In this case, it may a good idea to remember Joel Spolsky's "law of leaky abstractions" and think about what might happen at the asm level. But beware, you may be astonished how small the performance increasement will be when you replace a lambda construct by a "not so modern" language construct (at least, when using a decent C++ compiler).

  • 2
    +1 Concise, accurate, and easy to follow per usual Doc, glad we have you around here. Jul 8, 2013 at 16:05
  • Agreed, very clear answer.
    – cnd
    Jul 8, 2013 at 18:19

The choice between lambda and functor-class is a tradeoff.

The gain from lambda is mostly syntactic, by minimizing the amount of boilerplate and allowing conceptually-related code to be written inline, inside the function that is going to utilize it (immediately or later).

Performance-wise, this is no worse than a functor class, which is a C++ struct or class that contains a single "method". In fact, compilers treat lambda no differently than a compiler-generated functor class behind the scene.

// define the functor method somewhere
struct some_computer_generated_gibberish_0123456789
    int operator() (int x) const
        if (x == 2) return 5;
        if (x == 3) return 6;
        return 0;

// make a call
some_computer_generated_gibberish_0123456789 an_instance_of_0123456789;
int outputValue = an_instance_of_0123456789(inputValue);

In your code example, performance-wise it is no different from a function call, because that functor class happen to have no state (because it has an empty capture clause), thus requiring no allocation, constructor nor destruction.

int some_computer_generated_gibberish_0123456789_method_more_gibberish(int x)
    if (...) return ...;
    return ...;

Debugging any non-trivial C++ code using a disassembler has always been a difficult task. This is true with or without using lambda. This is caused by the sophisticated code optimization by C++ compiler that resulted in reordering, interleaving and dead code elimination.

The name-mangling aspect is somewhat unpalatable, and debugger support for lambda is still in its infancy. It can only be hoped that debugger support will improve over time.

Currently, the best way to debug lambda code is to use a debugger that supports setting breakpoints at the source code level, i.e. by specifying the source file name and the line number.


To add to the answer by @DocBrown, remember that these days CPU's are cheap but labour is expensive.

In the overall cost of a program, hardware is usually trivial in comparison to the cost of maintenance, which is by far the most expensive part of a typical project (even more than its development).

Therefore, your code needs to optimise maintenance above everything else, except when performance is critical (and even then maintenance needs to be considered).

  • Only partly true. If your code runs O(n^2) (quadratic) and you can make it something better say O(log(n)) (logarithmic) then hardware will never have a much performance increase as changing the code. In the case specified by the original poster this is very unlikely.
    – gnash117
    Jul 12, 2013 at 18:25
  • @gnash117 — yes, you are right if the code is to be run many times; thank you for pointing this out. In such cases, documenting the code clearly will keep it maintainable while allowing the performance improvement. Jul 12, 2013 at 18:41
  • "labor is expensive" - Correct. Your customer's time is very important and often expensive.
    – Cerad
    Aug 3, 2013 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.