Thích các thuật toán cho các vòng lặp viết tay?

Điều nào sau đây để bạn thấy dễ đọc hơn? Vòng lặp viết tay:

for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it)
{
    bar.process(*it);
}

Hoặc lời gọi thuật toán:

#include <algorithm>
#include <functional>

std::for_each(vec.begin(), vec.end(),
              std::bind1st(std::mem_fun_ref(&Bar::process), bar));

Tôi tự hỏi nếu std::for_eachnó thực sự có giá trị nó, đưa ra một ví dụ đơn giản như vậy đã yêu cầu rất nhiều mã.

Suy nghĩ của bạn về vấn đề này là gì?

Có một lý do mà lambdas được giới thiệu, và đó là bởi vì ngay cả Standard Commitee cũng nhận ra rằng hình thức thứ hai rất tệ. Sử dụng mẫu đầu tiên, cho đến khi bạn nhận được hỗ trợ C ++ 0x và lambda.

Luôn sử dụng biến thể mô tả tốt nhất những gì bạn định làm. Đó là

Đối với mỗi yếu tố xtrong vec, làm bar.process(x).

Bây giờ, hãy xem xét các ví dụ:

std::for_each(vec.begin(), vec.end(),
              std::bind1st(std::mem_fun_ref(&Bar::process), bar));

Chúng tôi cũng có một cái for_eachđó - yippeh . Chúng tôi có [begin; end)phạm vi chúng tôi muốn hoạt động.

Về nguyên tắc, thuật toán rõ ràng hơn nhiều và do đó thích hợp hơn bất kỳ triển khai viết tay nào. Nhưng sau đó ... Chất kết dính? Memfun? Về cơ bản C ++ interna làm thế nào để có được chức năng thành viên? Đối với nhiệm vụ của tôi, tôi không quan tâm đến họ! Tôi cũng không muốn phải chịu đựng cú pháp dài dòng, rùng rợn này.

Bây giờ khả năng khác:

for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it)
{
    bar.process(*it);
}

Cấp, đây là một mô hình phổ biến để nhận ra, nhưng ... tạo các vòng lặp, lặp, tăng, khử hội nghị. Đây cũng là tất cả những điều tôi không quan tâm để hoàn thành nhiệm vụ của mình.

Phải thừa nhận rằng, có vẻ waay tốt hơn so với các giải pháp đầu tiên (ít nhất, vòng cơ thể linh hoạt và khá rõ ràng), nhưng vẫn còn, nó không phải là thực sự là tuyệt vời. Chúng tôi sẽ sử dụng cái này nếu chúng tôi không có khả năng tốt hơn, nhưng có lẽ chúng tôi có ...

Một cách tốt hơn?

Bây giờ trở lại for_each. Sẽ không tuyệt vời khi nói theo nghĩa đen for_each và linh hoạt trong hoạt động sẽ được thực hiện, quá? May mắn thay, vì C ++ 0x lambdas, chúng tôi

for_each(v.begin(), v.end(), [&](const Foo& x) { bar.process(x); })

Bây giờ chúng tôi đã tìm thấy một giải pháp chung chung, trừu tượng cho nhiều tình huống liên quan, đáng chú ý là trong trường hợp cụ thể này, có một yêu thích tuyệt đối số 1 :

foreach(const Foo& x, vec) bar.process(x);

Nó thực sự không thể nhận được rõ ràng hơn nhiều. Rất may, C ++ 0x get của một cú pháp tương tự built-in !

Bởi vì điều này là không thể đọc được?

for (unsigned int i=0;i<vec.size();i++) {
{
    bar.process(vec[i]);
}

nói chung, hình thức đầu tiên có thể đọc được bởi khá nhiều người biết vòng lặp for là gì, bất kể nền tảng wat họ có là gì.

nói chung, cái thứ hai hoàn toàn không thể đọc được: đủ dễ để tìm ra những gì for_each đang làm, nhưng nếu bạn chưa bao giờ thấy std::bind1st(std::mem_fun_reftôi có thể tưởng tượng nó thật khó hiểu.

Thật ra, ngay cả với C ++ 0x, tôi không chắc for_eachsẽ nhận được nhiều tình yêu.

for(Foo& foo: vec) { bar.process(foo); }

Là cách dễ đọc hơn.

Một điều tôi không thích về các thuật toán (trong C ++) là chúng lập luận trên các trình vòng lặp, tạo ra các câu lệnh rất dài dòng.

Nếu bạn đã viết thanh như một functor thì nó sẽ đơn giản hơn rất nhiều:

// custom functor
class Bar
{    public: void operator()(Foo& value) { /* STUFF */ }
};


std::for_each(vec.begin(), vec.end(), Bar());

Ở đây mã khá dễ đọc.

Tôi thích cái sau vì nó gọn gàng và sạch sẽ. Nó thực sự là một phần của nhiều ngôn ngữ khác nhưng trong C ++, nó là một phần của thư viện. Nó không thực sự quan trọng.

Bây giờ vấn đề này thực sự không cụ thể đối với C ++, tôi sẽ tuyên bố.

Vấn đề là, chuyển một số functor vào một chức năng khác không có nghĩa là để thay thế các vòng lặp .
Nó được cho là đơn giản hóa một số mẫu nhất định, trở nên rất tự nhiên với lập trình chức năng, chẳng hạn như khách truy cập và người quan sát , chỉ cần đặt tên hai, ngay lập tức tôi nghĩ đến.
Trong các ngôn ngữ thiếu các hàm thứ tự đầu tiên (Java có lẽ là ví dụ tốt nhất), các cách tiếp cận như vậy luôn yêu cầu thực hiện một số giao diện nhất định, khá dài dòng và dư thừa.

Một cách sử dụng phổ biến tôi thấy rất nhiều trong các ngôn ngữ khác sẽ là:

someCollection.forEach(someUnaryFunctor);

Ưu điểm của việc này là, bạn không cần biết someCollectionthực tế được thực hiện như thế nào hoặc làm gì someUnaryFunctor. Tất cả những gì bạn cần biết là, forEachphương thức của nó sẽ lặp lại tất cả các phần tử của bộ sưu tập, chuyển chúng đến hàm đã cho.

Cá nhân, nếu bạn ở vị trí, có tất cả thông tin về cấu trúc dữ liệu bạn muốn lặp lại và tất cả thông tin về những gì bạn muốn làm trong mỗi bước lặp, thì cách tiếp cận chức năng là quá mức các thứ, đặc biệt là trong ngôn ngữ, nơi này xuất hiện khá tẻ nhạt.

Ngoài ra, bạn nên nhớ rằng cách tiếp cận chức năng chậm hơn, bởi vì bạn có rất nhiều cuộc gọi, với chi phí nhất định, mà bạn không có trong vòng lặp for.

Tôi nghĩ vấn đề ở đây for_eachkhông thực sự là một thuật toán, nó chỉ là một cách khác (và thường là kém hơn) để viết một vòng lặp viết tay. từ quan điểm này, nó phải là thuật toán tiêu chuẩn ít được sử dụng nhất và có lẽ bạn cũng có thể sử dụng một vòng lặp for. tuy nhiên, lời khuyên trong tiêu đề vẫn tồn tại vì có một số thuật toán tiêu chuẩn phù hợp với việc sử dụng cụ thể hơn.

Trường hợp có một thuật toán chặt chẽ hơn thực hiện những gì bạn muốn thì có, bạn nên ưu tiên các thuật toán hơn các vòng lặp viết tay. các ví dụ rõ ràng ở đây là sắp xếp với sorthoặc stable_sorthoặc tìm kiếm với lower_bound, upper_boundhoặc equal_range, nhưng hầu hết trong số chúng có một số tình huống trong đó chúng được ưu tiên sử dụng hơn một vòng lặp được mã hóa bằng tay.

Đối với đoạn mã nhỏ này, cả hai đều có thể đọc được bằng nhau. Nói chung, tôi thấy các vòng lặp thủ công dễ bị lỗi và thích sử dụng các thuật toán, nhưng nó thực sự phụ thuộc vào một tình huống cụ thể.