Tôi phải suy nghĩ về mã máy được biên dịch khi tôi viết mã của mình?

Ví dụ: tôi đã nhận được mã sau:

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

Và sau này tôi gọi điều này nhiều lần. Trong mã asm tôi thấy các cuộc gọi bên ngoài với lambda .... một cái gì đó ... Nó trở nên không dễ đọc và tôi nghĩ nó cũng có thể gây ra hiệu suất. Vì vậy, có thể tôi giành chiến thắng trong lập trình meta nhưng tôi có thua trong việc gỡ lỗi và hiệu suất không? Tôi có nên tránh các tính năng ngôn ngữ hiện đại, macro và các khía cạnh lập trình meta khác để chắc chắn về hiệu suất và gỡ lỗi đơn giản không?

Tôi phải suy nghĩ về mã máy được biên dịch khi tôi viết mã của mình?

Không , không phải khi bạn viết mã lần đầu tiên và không gặp phải bất kỳ vấn đề hiệu suất thực tế nào có thể đo lường được. Đối với hầu hết các nhiệm vụ, đây là trường hợp tiêu chuẩn. Suy nghĩ quá sớm về tối ưu hóa được gọi là "tối ưu hóa sớm" và có những lý do chính đáng tại sao D. Knuth gọi đó là "gốc rễ của mọi tội lỗi" .

Có , khi bạn đo lường một nút cổ chai hiệu năng thực sự có thể chứng minh được và bạn xác định cấu trúc lambda cụ thể đó là nguyên nhân gốc rễ. Trong trường hợp này, bạn nên nhớ "luật trừu tượng rò rỉ" của Joel Spolsky và suy nghĩ về những gì có thể xảy ra ở cấp độ asm. Nhưng hãy cẩn thận, bạn có thể ngạc nhiên về mức tăng hiệu suất sẽ nhỏ như thế nào khi bạn thay thế cấu trúc lambda bằng cấu trúc ngôn ngữ "không quá hiện đại" (ít nhất là khi sử dụng trình biên dịch C ++ đàng hoàng).

Sự lựa chọn giữa lambda và functor-class là một sự đánh đổi.

Thu được từ lambda chủ yếu là cú pháp, bằng cách giảm thiểu số lượng soạn sẵn và cho phép mã liên quan đến khái niệm được viết nội tuyến, bên trong hàm sẽ sử dụng nó (ngay lập tức hoặc sau đó).

Hiệu năng-khôn ngoan, điều này không tệ hơn một lớp functor , đó là một cấu trúc hoặc lớp C ++ có chứa một "phương thức" duy nhất. Trong thực tế, trình biên dịch đối xử với lambda không khác gì một lớp functor do trình biên dịch tạo ra đằng sau hậu trường.

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

Trong ví dụ mã của bạn, hiệu năng-khôn ngoan, nó không khác gì một hàm gọi, bởi vì lớp functor đó không có trạng thái (vì nó có một mệnh đề bắt trống), do đó không yêu cầu phân bổ, hàm tạo cũng như hủy.

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

Gỡ lỗi bất kỳ mã C ++ không tầm thường nào bằng cách sử dụng trình dịch ngược mã luôn là một nhiệm vụ khó khăn. Điều này đúng với hoặc không sử dụng lambda. Điều này được gây ra bởi việc tối ưu hóa mã tinh vi bởi trình biên dịch C ++ dẫn đến việc sắp xếp lại, xen kẽ và loại bỏ mã chết.

Khía cạnh xáo trộn tên là hơi khó chấp nhận và hỗ trợ trình gỡ lỗi cho lambda vẫn còn ở giai đoạn sơ khai . Chỉ có thể hy vọng rằng sự hỗ trợ của trình gỡ lỗi sẽ cải thiện theo thời gian.

Hiện tại, cách tốt nhất để gỡ lỗi mã lambda là sử dụng trình gỡ lỗi hỗ trợ đặt điểm dừng ở cấp mã nguồn, tức là bằng cách chỉ định tên tệp nguồn và số dòng.

Để thêm vào câu trả lời của @DocBrown, hãy nhớ rằng những ngày này CPU rất rẻ nhưng nhân công thì đắt.

Trong tổng chi phí của một chương trình, phần cứng thường không đáng kể so với chi phí bảo trì, đây là phần đắt nhất của một dự án điển hình (thậm chí còn hơn cả sự phát triển của nó).

Do đó, mã của bạn cần tối ưu hóa bảo trì trên tất cả mọi thứ khác, ngoại trừ khi hiệu suất là quan trọng (và thậm chí sau đó bảo trì cần phải được xem xét).