C++ 0x lambdas mã hóa kiểu

Question

Tôi tự hỏi làm thế nào mọi người đang sử dụng C++ 0x lambdas, về mặt phong cách mã hóa. Câu hỏi thú vị nhất là cách triệt để khi viết danh sách chụp. Một mặt, ngôn ngữ cho phép liệt kê các biến được nắm bắt một cách rõ ràng, và bởi "rõ ràng là tốt hơn so với quy tắc ngầm", do đó sẽ có ý nghĩa để thực hiện một danh sách đầy đủ để nêu rõ nội dung. Ví dụ:

int sum; 
std::for_each(xs.begin(), xs.end(), [&sum](int x) { sum += x }); 

Một lý do khác cho việc này là, vì tuổi thọ của người dân địa phương ref-chụp không thay đổi chỉ vì họ đang bị bắt (và do đó, một lambda có thể dễ dàng kết thúc tham khảo một địa phương mà đời từ lâu đã kết thúc), làm cho việc chụp rõ ràng giúp giảm các lỗi đó và theo dõi chúng.

Mặt khác, ngôn ngữ cũng cố tình cung cấp phím tắt để tự động chụp tất cả người dân địa phương được tham chiếu, vì vậy rõ ràng nó được dự định sẽ được sử dụng. Và người ta có thể tuyên bố rằng đối với một ví dụ như ở trên, điều rất rõ ràng những gì xảy ra ngay cả với tự động chụp, và tuổi thọ của lambda là nó sẽ không vượt quá phạm vi xung quanh, vì vậy không có lý do gì để không sử dụng nó:

int sum; 
std::for_each(xs.begin(), xs.end(), [&](int x) { sum += x }); 

rõ ràng điều này không phải là tất cả-hoặc-không có gì, nhưng phải có một số lý do để quyết định khi nào tự động chụp, và khi nào thì làm chụp một cách rõ ràng. Có suy nghĩ gì không?

Một câu hỏi khác trong cùng mạch là khi sử dụng tính năng chụp theo bản sao - [=] và khi nào sử dụng tính năng chụp theo tham chiếu - [&]. Capture-by-copy rõ ràng là an toàn hơn vì không có vấn đề suốt đời, vì vậy người ta có thể cho rằng nó nên được sử dụng theo mặc định bất cứ khi nào không cần phải thay đổi giá trị đã capture (hoặc xem những thay đổi được thực hiện từ nơi khác). tham chiếu không nên được coi là tối ưu hóa (có khả năng sớm) trong những trường hợp như vậy, chỉ được áp dụng khi nó tạo sự khác biệt rõ ràng. Mặt khác, capture-by-reference hầu như luôn luôn nhanh hơn (đặc biệt vì nó thường có thể được tối ưu hóa xuống một bản sao, nếu nó thực sự nhanh hơn, đối với các loại nhỏ và các chức năng mẫu không thể in được như hầu hết các thuật toán STL), và an toàn nếu lambda không bao giờ sống lâu hơn phạm vi của nó (cũng là trường hợp cho tất cả các thuật toán STL), vì vậy việc mặc định để capture-by-reference trong trường hợp này là một tối ưu hóa vô hại và không hại.

Suy nghĩ của bạn là gì?

Answer 1

Bản năng ban đầu của tôi là việc nắm bắt bằng giá trị cung cấp nhiều hay ít giống như các lớp bên trong vô danh của Java, là số lượng đã biết. Nhưng thay vì sử dụng thủ thuật mảng-of-size-1 khi bạn muốn phạm vi kèm theo có thể thay đổi, bạn có thể chụp bằng tham chiếu thay thế. Đó là trách nhiệm của bạn để hạn chế thời gian của lambda trong phạm vi của referand.

Trong thực tế, tôi đồng ý với bạn rằng việc chụp theo tham chiếu phải là mặc định khi xử lý các thuật toán, mà tôi mong đợi sẽ là phần lớn các công dụng. Một sử dụng phổ biến cho các lớp bên trong vô danh trong Java là người nghe. Có ít giao diện kiểu người nghe được nhìn thấy trong C++ để bắt đầu, vì vậy nó là một nhu cầu thấp hơn, nhưng vẫn còn ở đó. Nó có thể là tốt nhất để nghiêm túc dính vào nắm bắt bởi giá trị trong trường hợp đó, để tránh cơ hội cho lỗi. Liệu giá trị theo từng giá trị của shared_ptr có phải là thành ngữ lớn hay không?

Tuy nhiên, tôi chưa sử dụng lambdas, vì vậy tôi có thể đã bỏ lỡ điều gì đó rất lớn.

Answer 2

Tôi chưa bao giờ nghe nói đến quy tắc "rõ ràng là tốt hơn quy tắc ngầm" và tôi không đồng ý với quy tắc đó. Có những trường hợp nó là sự thật, tất nhiên, nhưng cũng có rất nhiều trường hợp mà nó không phải là. Đó là lý do tại sao 0x đang thêm suy luận kiểu với từ khóa auto sau khi tất cả.(và tại sao các tham số mẫu chức năng đã được suy ra khi có thể) Có nhiều trường hợp tiềm ẩn thích hợp hơn.

tôi đã không thực sự sử dụng C++ lambdas chưa (trừ chọc xung quanh với các phiên bản beta VC10), nhưng tôi muốn đi với hầu hết sau thời gian

std::for_each(xs.begin(), xs.end(), [&](int x) { sum += x }); 

lập luận của tôi? Tại sao không làm điều đó? Nó tiện lợi. Nó hoạt động. Và nó dễ dàng hơn để duy trì. Tôi không phải cập nhật danh sách chụp khi tôi sửa đổi phần thân của lambda. Tại sao tôi phải rõ ràng về điều gì đó mà trình biên dịch biết rõ hơn tôi? Trình biên dịch có thể tìm ra danh sách chụp dựa trên những gì thực sự được sử dụng.

Để chụp theo tham chiếu so với giá trị? Tôi sẽ áp dụng các quy tắc tương tự như tôi làm cho các chức năng thông thường. Nếu bạn cần ngữ nghĩa tham chiếu, hãy nắm bắt bằng tham chiếu. Nếu bạn cần sao chép ngữ nghĩa, hãy làm điều đó. Nếu một trong hai sẽ làm, thích giá trị cho các loại nhỏ, và tham khảo nếu sao chép là tốn kém.

Nó không có vẻ khác với sự lựa chọn bạn phải thực hiện khi thiết kế một chức năng thông thường.

Tôi có lẽ nên đọc thông số kỹ thuật cho lambdas, nhưng không phải là lý do chính cho danh sách chụp rõ ràng để bạn có thể nắm bắt một số biến theo giá trị và các biến khác theo tham chiếu?

Answer 3

Tôi có thể thấy quy tắc chuẩn mã hóa mới tại đây! ;)

Đây là một chút giả tạo nhưng chỉ để làm nổi bật một "lợi thế" để trở thành rõ ràng, hãy xem xét những điều sau đây:

void foo (std::vector<int> v, int x1) 
{ 
    int sum = 0; 
    std::for_each (v.begin() 
    , v.end() 
    , [&](int xl) { sum += x1; } 
} 

Bây giờ, tôi đã cố ý chọn tên người nghèo vv cho điều này, nhưng nó chỉ là để minh họa điểm. Nếu chúng ta sử dụng một danh sách chụp rõ ràng thì mã trên sẽ không biên dịch, nhưng hiện tại nó sẽ được biên dịch.

Trong một môi trường rất nghiêm ngặt (an toàn quan trọng), tôi có thể thấy một quy tắc như thế này là một phần của tiêu chuẩn mã hóa.

Answer 4

Tôi sẽ đi với danh sách chụp rõ ràng khi thuận tiện, khi bạn muốn chụp nhiều biến sau đó (có thể bạn đang làm gì đó sai) và bạn có thể sử dụng danh sách chụp tất cả [&].

Vấn đề của tôi là danh sách chụp rõ ràng là lý tưởng và các biến thể tiềm ẩn nên tránh và chỉ ở đó để mọi người sẽ không phải loại bỏ các đoạn mã khi chúng thực sự cần thiết.

Answer 5

Tôi đang đọc liên kết sau để hiểu rõ hơn về C++ lambda. Kiểu mã hóa được sử dụng trong các ví dụ khá gọn gàng và tôi có thể theo dõi: http://uint32t.blogspot.com/2009/05/using-c0x-lambda-to-replace-boost-bind.html