Lợi thế của việc sử dụng tham chiếu chuyển tiếp trong vòng lặp for dựa trên phạm vi là gì?

const auto&sẽ đủ nếu tôi muốn thực hiện các thao tác chỉ đọc. Tuy nhiên, tôi đã va vào

for (auto&& e : v)  // v is non-const

một vài lần gần đây. Điều này khiến tôi tự hỏi:

Có thể trong một số trường hợp góc khuất có một số lợi ích về hiệu suất trong việc sử dụng tham chiếu chuyển tiếp, so với auto&hoặc const auto&?

( shared_ptrlà nghi phạm cho các trường hợp góc khuất)

Cập nhật Hai ví dụ mà tôi tìm thấy trong mục yêu thích của mình:

Bất kỳ bất lợi nào của việc sử dụng tham chiếu const khi lặp qua các kiểu cơ bản?
Tôi có thể dễ dàng lặp lại các giá trị của bản đồ bằng vòng lặp for dựa trên phạm vi không?

Vui lòng tập trung vào câu hỏi: tại sao tôi muốn sử dụng tự động && trong các vòng lặp dựa trên phạm vi?

Ưu điểm duy nhất mà tôi có thể thấy là khi trình lặp trình tự trả về một tham chiếu proxy và bạn cần phải thao tác trên tham chiếu đó theo cách khác không. Ví dụ, hãy xem xét:

#include <vector>

int main()
{
    std::vector<bool> v(10);
    for (auto& e : v)
        e = true;
}

Điều này không biên dịch vì rvalue được vector<bool>::referencetrả về từ iteratorsẽ không liên kết với một tham chiếu lvalue không const. Nhưng điều này sẽ hoạt động:

#include <vector>

int main()
{
    std::vector<bool> v(10);
    for (auto&& e : v)
        e = true;
}

Tất cả những gì đang được nói, tôi sẽ không viết mã theo cách này trừ khi bạn biết bạn cần phải đáp ứng một trường hợp sử dụng như vậy. Tức là tôi sẽ không làm được điều này cách nhưng không vì nó không gây ra mọi người tự hỏi những gì bạn đang lên đến. Và nếu tôi đã làm điều đó, sẽ không có hại gì nếu bao gồm một bình luận tại sao:

#include <vector>

int main()
{
    std::vector<bool> v(10);
    // using auto&& so that I can handle the rvalue reference
    //   returned for the vector<bool> case
    for (auto&& e : v)
        e = true;
}

Biên tập

Trường hợp cuối cùng này của tôi thực sự nên là một khuôn mẫu có ý nghĩa. Nếu bạn biết vòng lặp luôn xử lý một tham chiếu proxy thì autocũng sẽ hoạt động auto&&. Nhưng khi vòng lặp đôi khi xử lý các tham chiếu không phải proxy và đôi khi là tham chiếu proxy, thì tôi nghĩ auto&&sẽ trở thành giải pháp được lựa chọn.

Sử dụng auto&&hoặc tham chiếu phổ quát với for-loop dựa trên phạm vi có lợi thế là bạn nắm bắt được những gì bạn nhận được. Đối với hầu hết các loại trình vòng lặp, bạn có thể nhận được một T&hoặc một T const&cho một số loại T. Trường hợp thú vị là khi tham chiếu một trình vòng lặp mang lại giá trị tạm thời: C ++ 2011 có các yêu cầu thoải mái và trình vòng lặp không nhất thiết phải mang lại giá trị. Việc sử dụng các tham chiếu chung phù hợp với chuyển tiếp đối số trong std::for_each():

template <typename InIt, typename F>
F std::for_each(InIt it, InIt end, F f) {
    for (; it != end; ++it) {
        f(*it); // <---------------------- here
    }
    return f;
}

Đối tượng chức năng fcó thể điều trị T&, T const&và Tkhác nhau. Tại sao phần thân của for-loop dựa trên phạm vi phải khác? Tất nhiên, để thực sự tận dụng lợi thế của việc suy ra loại bằng cách sử dụng các tham chiếu phổ quát, bạn cần chuyển chúng tương ứng:

for (auto&& x: range) {
    f(std::forward<decltype(x)>(x));
}

Tất nhiên, việc sử dụng std::forward()có nghĩa là bạn chấp nhận mọi giá trị trả về sẽ được chuyển từ đó. Liệu các đối tượng như thế này có ý nghĩa gì trong mã không phải mẫu hay không mà tôi chưa biết (?). Tôi có thể tưởng tượng rằng việc sử dụng các tham chiếu phổ quát có thể cung cấp thêm thông tin cho trình biên dịch để thực hiện Điều đúng. Trong mã mẫu, nó không đưa ra bất kỳ quyết định nào về những gì sẽ xảy ra với các đối tượng.

Tôi hầu như luôn luôn sử dụng auto&&. Tại sao lại bị cắn bởi một chiếc ốp cạnh khi bạn không cần phải làm vậy? Nó cũng ngắn hơn để nhập, và tôi chỉ đơn giản là thấy nó ... trong suốt hơn. Khi bạn sử dụng auto&& x, sau đó bạn biết xchính xác *it, mọi lúc.