Bao nhiêu là quá nhiều với từ khóa tự động C ++ 11?

Tôi đã sử dụng autotừ khóa mới có sẵn trong tiêu chuẩn C ++ 11 cho các loại khuôn mẫu phức tạp, đó là những gì tôi tin rằng nó được thiết kế cho. Nhưng tôi cũng đang sử dụng nó cho những việc như:

auto foo = std::make_shared<Foo>();

Và hoài nghi hơn cho:

auto foo = bla(); // where bla() return a shared_ptr<Foo>

Tôi chưa thấy nhiều cuộc thảo luận về chủ đề này. Dường như autocó thể bị lạm dụng, vì một loại thường là một dạng tài liệu và kiểm tra độ tỉnh táo. Nơi nào bạn vẽ đường trong việc sử dụng autovà các trường hợp sử dụng được đề xuất cho tính năng mới này là gì?

Để làm rõ: Tôi không yêu cầu một ý kiến ​​triết học; Tôi đang yêu cầu mục đích sử dụng từ khóa này của ủy ban tiêu chuẩn, có thể với các nhận xét về cách sử dụng mục đích đó được thực hiện trong thực tế.

Lưu ý bên lề: Câu hỏi này đã được chuyển đến SE.Programmer và sau đó quay lại Stack Overflow. Thảo luận về điều này có thể được tìm thấy trong câu hỏi meta này .

Tôi nghĩ rằng người ta nên sử dụng autotừ khóa bất cứ khi nào thật khó để nói cách viết loại từ cái nhìn đầu tiên, nhưng loại phía bên phải của một biểu thức là rõ ràng. Ví dụ: sử dụng:

my_multi_type::nth_index<2>::type::key_type::composite_key_type::
    key_extractor_tuple::tail_type::head_type::result_type

để có được loại khóa tổng hợp boost::multi_index, mặc dù bạn biết rằng đó là int. Bạn không thể viết intvì nó có thể được thay đổi trong tương lai. Tôi sẽ viết autotrong trường hợp này.

Vì vậy, nếu autotừ khóa cải thiện khả năng đọc trong một trường hợp cụ thể thì hãy sử dụng nó. Bạn có thể viết autokhi nó rõ ràng cho người đọc loại autođại diện.

Dưới đây là một số ví dụ:

auto foo = std::make_shared<Foo>();   // obvious
auto foo = bla();                     // unclear. don't know which type `foo` has

const size_t max_size = 100;
for ( auto x = max_size; x > 0; --x ) // unclear. could lead to the errors
                                      // since max_size is unsigned

std::vector<some_class> v;
for ( auto it = v.begin(); it != v.end(); ++it )
                                      // ok, since I know that `it` has an iterator type
                                      // (don't really care which one in this context)

Sử dụng autoở mọi nơi mà bạn có thể đặc biệt const autođể các tác dụng phụ ít phải quan tâm hơn. Bạn sẽ không phải lo lắng về các loại ngoại trừ trong các trường hợp rõ ràng, nhưng chúng vẫn sẽ được xác minh tĩnh cho bạn và bạn có thể tránh một số sự lặp lại. Nếu autokhông khả thi, bạn có thể sử dụng decltypeđể thể hiện các loại về mặt ngữ nghĩa dưới dạng hợp đồng dựa trên biểu thức. Mã của bạn sẽ trông khác nhau, nhưng nó sẽ là một thay đổi tích cực.

Dễ dàng. Sử dụng nó khi bạn không quan tâm loại đó là gì. Ví dụ

for (const auto & i : some_container) {
   ...

Tất cả những gì tôi quan tâm ở đây ilà bất cứ thứ gì trong container.

Nó hơi giống typedefs.

typedef float Height;
typedef double Weight;
//....
Height h;
Weight w;

Ở đây, tôi không quan tâm liệu hvà wlà phao hoặc đôi, chỉ rằng họ là bất cứ loại thích hợp để diễn tả chiều cao và trọng lượng .

Hoặc xem xét

for (auto i = some_container .begin (); ...

Ở đây tất cả những gì tôi quan tâm là nó là một trình vòng lặp phù hợp, hỗ trợ operator++(), nó giống như kiểu gõ vịt trong khía cạnh này.

Ngoài ra loại lambdas không thể đánh vần, auto f = []...phong cách cũng tốt. Sự thay thế là đúc std::functionnhưng đi kèm với chi phí.

Tôi không thể thực sự quan niệm về một "lạm dụng" auto. Cách gần nhất tôi có thể tưởng tượng là tước đi một chuyển đổi rõ ràng thành một loại quan trọng - nhưng bạn sẽ không sử dụng autocho điều đó, bạn sẽ xây dựng một đối tượng của loại mong muốn.

Nếu bạn có thể loại bỏ một số dư thừa trong mã của bạn mà không cần giới thiệu tác dụng phụ, sau đó nó phải là tốt để làm như vậy.

Counterexamples (mượn từ câu trả lời của người khác):

auto i = SomeClass();
for (auto x = make_unsigned (y); ...)

Ở đây chúng tôi quan tâm loại này là gì, vì vậy chúng tôi nên viết Someclass i;vàfor(unsigned x = y;...

Cứ liều thử đi. Sử dụng autobất cứ nơi nào nó làm cho việc viết mã dễ dàng hơn.

Mỗi tính năng mới trong bất kỳ ngôn ngữ nào sẽ bị lạm dụng bởi ít nhất một số loại lập trình viên. Chỉ thông qua việc sử dụng quá mức vừa phải bởi một số lập trình viên có kinh nghiệm (không phải noobs) mà phần còn lại của các lập trình viên có kinh nghiệm tìm hiểu ranh giới của việc sử dụng đúng. Việc sử dụng quá mức thường là xấu, nhưng có thể là tốt vì việc lạm dụng như vậy có thể dẫn đến những cải tiến trong tính năng hoặc một tính năng tốt hơn để thay thế nó.

Nhưng nếu tôi đang làm việc với mã với hơn một vài dòng như

auto foo = bla();

trong đó loại được biểu thị bằng 0 lần, tôi có thể muốn thay đổi các dòng đó để bao gồm các loại. Ví dụ đầu tiên là tuyệt vời vì loại được nêu một lần và autogiúp chúng ta không phải viết các loại templated lộn xộn hai lần. Hoan hô cho C ++++. Nhưng hiển thị rõ ràng loại 0 lần, nếu nó không dễ dàng nhìn thấy trong một dòng gần đó, khiến tôi lo lắng, ít nhất là trong C ++ và những người kế nhiệm ngay lập tức. Đối với các ngôn ngữ khác được thiết kế để hoạt động ở cấp độ cao hơn với tính trừu tượng, đa hình và tính tổng quát hơn, điều đó tốt.

Tại C ++ và Beyond 2012 trong bảng điều khiển Ask Us Anything , đã có một cuộc trao đổi tuyệt vời giữa Andrei Alexandrescu, Scott Meyers và Herb Sutter nói về khi nào nên sử dụng và không sử dụngauto . Bỏ qua đến phút 25:03 để thảo luận 4 phút. Tất cả ba loa cho điểm tuyệt vời nên được lưu ý khi không sử dụng auto.

Tôi rất khuyến khích mọi người đi đến kết luận của riêng họ, nhưng việc tôi bỏ đi là sử dụng autoở mọi nơi trừ khi :

1. Nó làm tổn thương khả năng đọc
2. Có mối quan tâm về chuyển đổi loại tự động (ví dụ: từ nhà xây dựng, chuyển nhượng, loại trung gian mẫu, chuyển đổi ngầm định giữa độ rộng số nguyên)

Việc sử dụng tự do explicitgiúp giảm bớt mối quan tâm cho người sau, điều này giúp giảm thiểu lượng thời gian trước đây là một vấn đề.

Đọc lại những gì Herb nói, "nếu bạn không làm X, Y và Z, hãy sử dụng auto. Tìm hiểu X, Y và Z là gì và đi ra ngoài và sử dụng autoở mọi nơi khác."

Vâng, nó có thể được sử dụng quá mức gây hại cho khả năng đọc. Tôi đề nghị sử dụng nó trong các bối cảnh nơi các loại chính xác dài, hoặc không gây nhiễu, hoặc không quan trọng đối với khả năng đọc và các biến chỉ tồn tại trong thời gian ngắn. Ví dụ, loại lặp thường dài và không quan trọng, vì vậy autosẽ hoạt động:

   for(auto i = container.begin(); i != container.end(); ++i);

auto ở đây không làm tổn thương khả năng đọc.

Một ví dụ khác là loại quy tắc phân tích cú pháp, có thể dài và phức tạp. Đối chiếu:

   auto spaces = space & space & space;

với

r_and_t<r_and_t<r_char_t<char>&, r_char_t<char>&>, r_char_t<char>&> spaces = 
   space & space & space;

Mặt khác, khi loại được biết đến và đơn giản, sẽ tốt hơn nhiều nếu nó được nêu rõ ràng:

int i = foo();

thay vì

auto i = foo();

auto có thể rất nguy hiểm khi kết hợp với các mẫu biểu thức được sử dụng rất nhiều bởi các thư viện đại số tuyến tính như Eigen hoặc OpenCV.

auto A = Matrix(...);
auto B = Matrix(...);
auto C = A * B; // C is not a matrix. It is a matrix EXPRESSION.
cout << C; // The expression is evaluated and gives the expected result.
... // <code modifying A or B>
cout << C; // The expression is evaluated AGAIN and gives a DIFFERENT result.

Lỗi gây ra bởi loại sai lầm này là một nỗi đau lớn để gỡ lỗi. Một biện pháp khắc phục có thể là phân phối rõ ràng kết quả cho loại dự kiến ​​nếu bạn không thích sử dụng tự động cho kiểu khai báo từ trái sang phải.

auto C = Matrix(A * B); // The expression is now evaluated immediately.

Tôi sử dụng autohạn chế wihout và không gặp phải bất kỳ vấn đề nào. Tôi thậm chí đôi khi cuối cùng sử dụng nó cho các loại đơn giản như int. Điều này làm cho c ++ trở thành ngôn ngữ cấp cao hơn đối với tôi và cho phép khai báo biến trong c ++ như trong python. Sau khi viết mã python, đôi khi tôi viết

auto i = MyClass();

thay vì

MyClass i;

Đây là một trường hợp mà tôi muốn nói đó là lạm dụng autotừ khóa.

Thường thì tôi không quan tâm loại chính xác của đối tượng là gì, tôi quan tâm nhiều hơn đến tính hư cấu của nó và vì các tên hàm thường nói điều gì đó về các đối tượng chúng trả về, autokhông gây tổn thương: ví dụ: auto s = mycollection.size()tôi có thể đoán đó ssẽ là một loại số nguyên và trong trường hợp hiếm hoi tôi quan tâm đến loại chính xác, hãy kiểm tra nguyên mẫu hàm sau đó (ý tôi là, tôi muốn kiểm tra khi tôi cần thông tin, thay vì tiên nghiệm khi viết mã, chỉ trong trường hợp nó sẽ hữu ích một ngày nào đó, như trong int_type s = mycollection.size()).

Liên quan đến ví dụ này từ câu trả lời được chấp nhận:

for ( auto x = max_size; x > 0; --x )

Trong mã của tôi, tôi vẫn sử dụng autotrong trường hợp này và nếu tôi muốn xkhông dấu, thì tôi sử dụng một hàm tiện ích, có tên là say make_unsigned, thể hiện rõ mối quan tâm của tôi:

for ( auto x = make_unsigned(max_size); x > 0; --x )

từ chối trách nhiệm: Tôi chỉ mô tả việc sử dụng của tôi , tôi không đủ khả năng để đưa ra lời khuyên!

Một trong những vấn đề lớn với chương trình C ++ là nó cho phép bạn sử dụng biến chưa được khởi tạo . Điều này dẫn chúng ta đến hành vi chương trình phi quyết định khó chịu. Cần lưu ý rằng trình biên dịch hiện đại bây giờ ném các thông báo cảnh báo / tin nhắn thích hợp nếu lốp chương trình sử dụng nó.

Chỉ để minh họa điều này, hãy xem xét bên dưới chương trình c ++:

int main() {
    int x;
    int y = 0;
    y += x;
}

Nếu tôi biên dịch chương trình này bằng trình biên dịch hiện đại (GCC), nó sẽ đưa ra cảnh báo. Cảnh báo như vậy có thể không rõ ràng nếu chúng ta đang làm việc với mã sản xuất phức tạp thực sự.

main.cpp: Trong hàm 'int main ()':

main.cpp: 4: 8: cảnh báo : 'x' được sử dụng chưa được khởi tạo trong chức năng này [-Wuninitialized]

y + = x;

    ^

================================================== =============================== Bây giờ nếu chúng ta thay đổi chương trình sử dụng tự động , sau đó biên dịch chúng ta sẽ nhận được như sau:

int main() {
    auto x;
    auto y = 0;
    y += x;
}

main.cpp: Trong hàm 'int main ()':

main.cpp: 2: 10: error : khai báo 'auto x' không có trình khởi tạo

 auto x;

      ^

Với auto, không thể sử dụng biến chưa được khởi tạo. Đây là lợi thế lớn mà chúng tôi có thể nhận được (miễn phí), nếu chúng tôi bắt đầu sử dụng tự động .

Khái niệm này và khái niệm C ++ hiện đại tuyệt vời khác được giải thích bởi chuyên gia C ++ Herb Shutter trong bài nói chuyện về CppCon14 của ông :

Quay lại vấn đề cơ bản! Yếu tố cần thiết của phong cách C ++ hiện đại

Một mối nguy hiểm tôi đã lưu ý là về các tài liệu tham khảo. ví dụ

MyBigObject& ref_to_big_object= big_object;
auto another_ref = ref_to_big_object; // ?

Vấn đề là other_Vf không thực sự là một tài liệu tham khảo trong trường hợp này, đó là MyBigObject thay vì MyBigObject &. Bạn cuối cùng sao chép một đối tượng lớn mà không nhận ra nó.

Nếu bạn đang nhận được một tài liệu tham khảo trực tiếp từ một phương pháp, bạn có thể không nghĩ về nó thực sự là gì.

auto another_ref = function_returning_ref_to_big_object();

bạn sẽ cần "tự động &" hoặc "const auto &"

MyBigObject& ref_to_big_object= big_object;
auto& another_ref = ref_to_big_object;
const auto& yet_another_ref = function_returning_ref_to_big_object();

Sử dụng autoở nơi có ý nghĩa cho một loại được suy ra. Nếu bạn có thứ gì đó mà bạn biết là số nguyên hoặc bạn biết đó là một chuỗi, chỉ cần sử dụng int / std :: string, v.v. Tôi sẽ không lo lắng về việc "lạm dụng" một tính năng ngôn ngữ trừ khi nó đến mức vô lý, hoặc mã obfuscates.

Dù sao đó cũng là ý kiến ​​của tôi.

autotừ khóa chỉ có thể được sử dụng cho biến cục bộ, không phải cho các đối số hoặc thành viên lớp / cấu trúc. Vì vậy, nó là an toàn và khả thi để sử dụng chúng bất cứ nơi nào bạn muốn. Tôi sử dụng chúng rất nhiều. Loại được suy luận tại thời gian biên dịch, trình gỡ lỗi hiển thị loại trong khi gỡ lỗi, sizeofbáo cáo chính xác, decltypesẽ cung cấp loại chính xác - không có hại. Tôi không được tính autolà quá lạm dụng!

TL; DR: Xem quy tắc ngón tay cái ở phía dưới.

Các câu trả lời được chấp nhận gợi ý các nguyên tắc sau của ngón tay cái:

Sử dụng autobất cứ khi nào thật khó để nói cách viết loại từ cái nhìn đầu tiên, nhưng loại phía bên phải của biểu thức là rõ ràng.

Nhưng tôi sẽ nói rằng đó là quá hạn chế. Đôi khi tôi không quan tâm đến các loại, vì tuyên bố là đủ thông tin mà tôi không bận tâm dành thời gian để tìm ra loại. Ý tôi là gì? Hãy xem xét ví dụ đã xuất hiện trong một số câu trả lời:

auto x = f();

Điều gì làm cho đây là một ví dụ về việc sử dụng sai auto? Có phải là sự thiếu hiểu biết của tôi f()về loại trả lại? Chà, nó thực sự có thể giúp nếu tôi biết điều đó, nhưng - đó không phải là mối quan tâm chính của tôi. Nhiều hơn một vấn đề là điều đó xvà f()khá vô nghĩa. Nếu chúng ta có:

auto nugget = mine_gold();

thay vào đó, sau đó tôi thường không quan tâm liệu kiểu trả về của hàm có rõ ràng hay không. Đọc tuyên bố, tôi biết những gì tôi đang làm và tôi biết đủ về ngữ nghĩa của giá trị trả về để không cảm thấy tôi cũng cần biết loại của nó.

Vì vậy, câu trả lời của tôi là: Sử dụng autobất cứ khi nào trình biên dịch cho phép, trừ khi:

• Bạn cảm thấy tên biến cùng với biểu thức khởi tạo / gán không cung cấp đủ thông tin về những gì câu lệnh đang làm.
• Bạn cảm thấy tên biến cùng với biểu thức khởi tạo / gán cung cấp thông tin "sai lệch" về loại nên là - nghĩa là, nếu bạn phải đoán cái gì đến thay vì tự động, bạn sẽ có thể đoán - và nó sẽ là sai và giả định sai này có hậu quả sau đó trong mã.
• Bạn muốn buộc một loại khác (ví dụ: một tài liệu tham khảo).

Và cũng:

• Thích đặt tên có ý nghĩa (không chứa tên loại khóa học) trước khi thay thế autobằng loại cụ thể.

Một trong những trải nghiệm cay đắng của tôi autolà sử dụng nó với các biểu thức lambda :

auto i = []() { return 0; };
cout<<"i = "<<i<<endl; // output: 1 !!!

Trên thực tế, ở đây iđược giải quyết để con trỏ chức năng của int(*)(). Đây chỉ là một đơn giản cout, nhưng chỉ cần tưởng tượng loại lỗi biên dịch / thời gian chạy xấu mà nó có thể gây ra khi sử dụng template.

Bạn nên tránh auto với các biểu thức như vậy và đặt một returnloại thích hợp (hoặc được kiểm soát decltype())

Sử dụng đúng cho ví dụ trên sẽ là,

auto i = []() { return 0; }(); // and now i contains the result of calling the lambda