コードを書くとき、コンパイルされたマシンコードについて考える必要がありますか？

たとえば、次のコードがあります。

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

そして、後でこれを数回呼び出します。asmコードでは、ラムダを使用した外部呼び出しが表示されます。メタプログラミングで勝つかもしれませんが、asmのデバッグとパフォーマンスで負けるのですか？パフォーマンスとデバッグの単純さを確実にするために、最新の言語機能、マクロ、およびその他のメタプログラミングの側面を避ける必要がありますか？

コードを書くとき、コンパイルされたマシンコードについて考える必要がありますか？

いいえ、初めてコードを書いたときで、実際の測定可能なパフォーマンスの問題に悩まされていません。ほとんどのタスクでは、これが標準的なケースです。最適化についてあまりにも早く考えることは「時期尚早の最適化」と呼ばれ、D。クヌースがそれを「すべての悪の根源」と呼ぶ正当な理由があります。

はい、実際の証明可能なパフォーマンスのボトルネックを測定し、その特定のラムダ構造を根本原因として特定した場合。この場合、Joel Spolskyの「漏れやすい抽象化の法則」を覚えて、asmレベルで何が起こるかを考えることをお勧めします。ただし、ラムダ構造を「それほど現代的ではない」言語構造に置き換えると（少なくとも、まともなC ++コンパイラを使用する場合）、パフォーマンスの向上がどれほど小さくなるかに注意してください。

lambdaとfunctor-classの選択はトレードオフです。

ボイラープレートの量を最小限に抑え、概念的に関連するコードを（すぐにまたは後で）それを利用する関数内にインラインで記述できるようにすることで、ラムダからの利益はほとんど構文的です。

パフォーマンスの面では、これは、単一の「メソッド」を含むC ++構造体またはクラスであるファンクタークラスよりも悪くありません。実際、コンパイラはラムダを、背後でコンパイラが生成したファンクタクラスと同じように扱います。

// 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);

コード例では、パフォーマンス面では関数呼び出しと違いはありません。そのファンクタークラスには状態がないため（空のキャプチャ句があるため）、割り当て、コンストラクタ、または破棄が不要です。

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

逆アセンブラを使用して重要でないC ++コードをデバッグすることは、常に困難な作業でした。これは、ラムダを使用してもしなくても当てはまります。これは、C ++コンパイラーによる洗練されたコード最適化が原因で、並べ替え、インターリーブ、デッドコードの削除が発生します。

名前をマングルするという側面はやや不愉快であり、ラムダのデバッガーサポートはまだ初期段階にあります。デバッガーのサポートが時間の経過とともに向上することが期待されるだけです。

現在、ラムダコードをデバッグする最良の方法は、ソースコードレベルでのブレークポイントの設定をサポートするデバッガーを使用することです。つまり、ソースファイル名と行番号を指定することです。

@DocBrownによる回答に追加するには、最近のCPUは安価ですが、人件費が高いことに注意してください。

プログラムの全体的なコストの中で、ハードウェアは通常、保守のコストと比較してささいなものです。保守のコストは、典型的なプロジェクトの中で最も高価な部分です（開発よりもさらに）。

したがって、パフォーマンスが重要な場合（および保守を検討する必要がある場合を除く）を除き、コードは他のすべてよりも保守を最適化する必要があります。