Có một nhược điểm nào khi khai báo các biến với auto trong C ++ không?

Có vẻ như đó autolà một tính năng khá quan trọng được thêm vào trong C ++ 11 dường như đi theo rất nhiều ngôn ngữ mới hơn. Như với một ngôn ngữ như Python, tôi chưa thấy bất kỳ khai báo biến rõ ràng nào (tôi không chắc có thể sử dụng các tiêu chuẩn Python hay không).

Có một hạn chế nào trong việc sử dụng autođể khai báo các biến thay vì khai báo rõ ràng không?

Bạn chỉ hỏi về những nhược điểm, vì vậy tôi nhấn mạnh một vài trong số đó. Khi sử dụng tốt, autocó một số lợi thế là tốt. Những hạn chế là do dễ lạm dụng và tăng tiềm năng cho mã để hành xử theo những cách không lường trước được.

Hạn chế chính là, bằng cách sử dụng auto, bạn không nhất thiết phải biết loại đối tượng được tạo. Cũng có những lúc lập trình viên có thể mong đợi trình biên dịch suy ra một loại, nhưng trình biên dịch lại suy diễn một cách khéo léo một loại khác.

Đưa ra một tuyên bố như

auto result = CallSomeFunction(x,y,z);

bạn không nhất thiết phải có kiến ​​thức về loại hình result. Nó có thể là một int. Nó có thể là một con trỏ. Nó có thể là một cái gì đó khác. Tất cả những hỗ trợ hoạt động khác nhau. Bạn cũng có thể thay đổi đáng kể mã bằng một thay đổi nhỏ như

auto result = CallSomeFunction(a,y,z);

bởi vì, tùy thuộc vào những gì quá tải tồn tại cho CallSomeFunction()loại kết quả có thể hoàn toàn khác nhau - và do đó mã tiếp theo có thể hành xử hoàn toàn khác với dự định. Bạn có thể đột nhiên kích hoạt các thông báo lỗi trong mã sau này (ví dụ sau đó đang cố gắng hủy đăng ký int, cố gắng thay đổi một cái gì đó hiện tại const). Sự thay đổi độc ác hơn là nơi thay đổi của bạn lướt qua trình biên dịch, nhưng mã tiếp theo hành xử theo những cách khác nhau và không xác định - có thể là lỗi -.

Không có kiến ​​thức rõ ràng về loại của một số biến do đó làm cho khó khăn hơn để biện minh một cách nghiêm ngặt cho một tuyên bố rằng mã hoạt động như dự định. Điều này có nghĩa là có nhiều nỗ lực hơn để biện minh cho các tuyên bố "phù hợp với mục đích" trong các lĩnh vực có mức độ quan trọng cao (ví dụ như an toàn hoặc quan trọng cho nhiệm vụ).

Một nhược điểm khác, phổ biến hơn, là sự cám dỗ cho một lập trình viên sử dụng autonhư một công cụ cùn để buộc mã để biên dịch, thay vì suy nghĩ về những gì mã đang làm và làm việc để làm cho đúng.

Đây không phải là một nhược điểm của automột cách chính xác, nhưng về mặt thực tế, nó dường như là một vấn đề đối với một số người. Về cơ bản, một số người: a) coi autonhư một vị cứu tinh cho các loại và tắt não khi sử dụng nó, hoặc b) quên rằng autoluôn luôn suy luận về các loại giá trị. Điều này khiến mọi người làm những việc như thế này:

auto x = my_obj.method_that_returns_reference();

Rất tiếc, chúng tôi chỉ sao chép sâu một số đối tượng. Đó thường là một lỗi hoặc một hiệu suất thất bại. Sau đó, bạn cũng có thể xoay theo cách khác:

const auto& stuff = *func_that_returns_unique_ptr();

Bây giờ bạn có được một tài liệu tham khảo lơ lửng. Những vấn đề này hoàn toàn không gây ra auto, vì vậy tôi không coi chúng là những lý lẽ hợp pháp chống lại nó. Nhưng có vẻ như autolàm cho những vấn đề này trở nên phổ biến hơn (từ kinh nghiệm cá nhân của tôi), vì những lý do tôi liệt kê lúc đầu.

Tôi nghĩ rằng thời gian nhất định mọi người sẽ điều chỉnh và hiểu sự phân công lao động: autosuy ra kiểu cơ bản, nhưng bạn vẫn muốn nghĩ về tham chiếu và không tham gia. Nhưng nó mất một chút thời gian.

Các câu trả lời khác đang đề cập đến những hạn chế như "bạn không thực sự biết loại biến là gì". Tôi muốn nói rằng điều này phần lớn liên quan đến quy ước đặt tên cẩu thả trong mã. Nếu giao diện của bạn được đặt tên rõ ràng, bạn không cần quan tâm loại chính xác là gì. Chắc chắn, auto result = callSomeFunction(a, b);không nói với bạn nhiều. Nhưng auto valid = isValid(xmlFile, schema);cho bạn biết đủ để sử dụng validmà không cần phải quan tâm loại chính xác của nó là gì. Rốt cuộc, chỉ với if (callSomeFunction(a, b)), bạn cũng sẽ không biết loại này. Tương tự với bất kỳ đối tượng tạm thời phụ khác. Vì vậy, tôi không coi đây là một nhược điểm thực sự auto.

Tôi muốn nói rằng nhược điểm chính của nó là đôi khi, kiểu trả về chính xác không phải là thứ bạn muốn làm việc. Trong thực tế, đôi khi loại trả về thực tế khác với loại trả về "logic" như một chi tiết thực hiện / tối ưu hóa. Mẫu biểu thức là một ví dụ điển hình. Hãy nói rằng chúng ta có điều này:

SomeType operator* (const Matrix &lhs, const Vector &rhs);

Logic, chúng tôi mong chờ SomeTypeđược Vector, và chúng tôi chắc chắn muốn đối xử với nó như vậy trong mã của chúng tôi. Tuy nhiên, có thể vì mục đích tối ưu hóa, thư viện đại số chúng tôi đang sử dụng các mẫu biểu thức và loại trả về thực tế là:

MultExpression<Matrix, Vector> operator* (const Matrix &lhs, const Vector &rhs);

Bây giờ, vấn đề là MultExpression<Matrix, Vector>trong tất cả khả năng sẽ lưu trữ một const Matrix&và const Vector&nội bộ; nó hy vọng rằng nó sẽ chuyển đổi thành Vectortrước khi kết thúc biểu thức đầy đủ của nó. Nếu chúng ta có mã này, tất cả đều tốt:

extern Matrix a, b, c;
extern Vector v;

void compute()
{
  Vector res = a * (b * (c * v));
  // do something with res
}

Tuy nhiên, nếu chúng tôi đã sử dụng autoở đây, chúng tôi có thể gặp rắc rối:

void compute()
{
  auto res = a * (b * (c * v));
  // Oops! Now `res` is referring to temporaries (such as (c * v)) which no longer exist
}

Một trong những nhược điểm là đôi khi bạn không thể tuyên bố const_iteratorvới auto. Bạn sẽ nhận được trình lặp thông thường (không const) trong ví dụ về mã được lấy từ câu hỏi này :

map<string,int> usa;
//...init usa
auto city_it = usa.find("New York");

Nó làm cho mã của bạn khó hơn một chút, hoặc tẻ nhạt, để đọc. Hãy tưởng tượng một cái gì đó như thế:

auto output = doSomethingWithData(variables);

Bây giờ, để tìm ra loại đầu ra, bạn phải theo dõi chữ ký của doSomethingWithDatahàm.

Giống như nhà phát triển này , tôi ghét auto. Hay đúng hơn, tôi ghét cách mọi người sử dụng sai auto.

Tôi có ý kiến ​​(mạnh mẽ) autolà để giúp bạn viết mã chung chung, không phải để giảm việc gõ .
C ++ là ngôn ngữ có mục tiêu là cho phép bạn viết mã mạnh mẽ, không giảm thiểu thời gian phát triển.
Điều này khá rõ ràng từ nhiều tính năng của C ++, nhưng thật không may, một vài trong số những tính năng mới hơn như thế autolàm giảm việc đánh lừa mọi người nghĩ rằng họ nên bắt đầu lười biếng với việc gõ.

Trước autođây, mọi người đã sử dụng typedefs, điều này thật tuyệt vời vì typedef cho phép người thiết kế thư viện giúp bạn tìm ra loại trả về nên là gì, để thư viện của họ hoạt động như mong đợi. Khi bạn sử dụng auto, bạn lấy đi quyền điều khiển đó từ trình thiết kế của lớp và thay vào đó, hãy yêu cầu trình biên dịch tìm ra loại nên là gì, loại bỏ một trong những công cụ C ++ mạnh nhất khỏi hộp công cụ và có nguy cơ phá vỡ mã của chúng.

Nói chung, nếu bạn sử dụng auto, thì đó là do mã của bạn hoạt động với bất kỳ loại hợp lý nào , không phải vì bạn quá lười để viết ra loại mà nó nên hoạt động. Nếu bạn sử dụng autonhư một công cụ để giúp đỡ sự lười biếng, thì điều xảy ra là cuối cùng bạn bắt đầu đưa ra các lỗi tinh vi trong chương trình của mình, thường là do các chuyển đổi ngầm không xảy ra do bạn đã sử dụng auto.

Thật không may, các lỗi này rất khó để minh họa trong một ví dụ ngắn ở đây vì tính ngắn gọn của chúng khiến chúng kém thuyết phục hơn so với các ví dụ thực tế xuất hiện trong dự án người dùng - tuy nhiên, chúng xảy ra dễ dàng trong mã nặng mẫu mong đợi các chuyển đổi ngầm định sẽ thực hiện địa điểm.

Nếu bạn muốn một ví dụ, có một ở đây . Mặc dù vậy, một lưu ý nhỏ: trước khi bị cám dỗ nhảy và chỉ trích mã: hãy nhớ rằng nhiều thư viện nổi tiếng và trưởng thành đã được phát triển xung quanh các chuyển đổi ngầm định đó và chúng ở đó vì chúng giải quyết các vấn đề có thể khó khăn nếu không phải là không thể để giải quyết khác. Hãy cố gắng tìm ra một giải pháp tốt hơn trước khi chỉ trích họ.

autokhông có nhược điểm cho mỗi gia nhập , và tôi ủng hộ để (tay wavily) sử dụng nó ở khắp mọi nơi trong mã mới. Nó cho phép mã của bạn kiểm tra kiểu một cách nhất quán và nhất quán tránh bị cắt im lặng. (Nếu Bxuất phát từ Avà một hàm trả về Ađột ngột trả về B, thì autohoạt động như mong đợi để lưu trữ giá trị trả về của nó)

Mặc dù, mã kế thừa tiền C ++ 11 có thể dựa vào các chuyển đổi ngầm định gây ra bởi việc sử dụng các biến được gõ rõ ràng. Thay đổi một biến được gõ rõ ràng để autocó thể thay đổi hành vi mã , vì vậy tốt hơn hết bạn nên thận trọng.

Từ khóa autochỉ cần suy ra loại từ giá trị trả về. Do đó, nó không tương đương với một đối tượng Python, vd

# Python
a
a = 10       # OK
a = "10"     # OK
a = ClassA() # OK

// C++
auto a;      // Unable to deduce variable a
auto a = 10; // OK
a = "10";    // Value of const char* can't be assigned to int
a = ClassA{} // Value of ClassA can't be assigned to int
a = 10.0;    // OK, implicit casting warning

Vì autođược suy luận trong quá trình biên dịch, nó sẽ không có bất kỳ nhược điểm nào trong thời gian chạy.

Điều mà không ai đề cập ở đây cho đến nay, nhưng đối với bản thân nó là giá trị câu trả lời nếu bạn hỏi tôi.

Vì (ngay cả khi mọi người nên biết rằng C != C++) mã được viết bằng C có thể dễ dàng được thiết kế để cung cấp cơ sở cho mã C ++ và do đó được thiết kế mà không cần quá nhiều nỗ lực để tương thích với C ++, đây có thể là một yêu cầu cho thiết kế.

Tôi biết về một số quy tắc trong đó một số cấu trúc được xác định rõ Clà không hợp lệ C++và ngược lại. Nhưng điều này chỉ đơn giản là dẫn đến các thực thi bị hỏng và mệnh đề UB đã biết áp dụng mà hầu hết các lần được chú ý bởi các vòng lặp lạ dẫn đến sự cố hoặc bất cứ điều gì (hoặc thậm chí có thể không bị phát hiện, nhưng điều đó không quan trọng ở đây).

Nhưng đây autolà lần đầu tiên ¹ thay đổi này!

Hãy tưởng tượng bạn đã sử dụng autolàm công cụ xác định lớp lưu trữ trước đó và chuyển mã. Nó thậm chí sẽ không nhất thiết (tùy thuộc vào cách nó được sử dụng) "phá vỡ"; nó thực sự có thể âm thầm thay đổi hành vi của chương trình.

Đó là điều người ta nên ghi nhớ.

¹ _{Ít nhất là lần đầu tiên tôi biết.}

Một lý do mà tôi có thể nghĩ đến là bạn mất cơ hội cưỡng chế lớp học được trả lại. Nếu chức năng hoặc phương thức của bạn trả về 64 bit dài và bạn chỉ muốn một số nguyên không dấu 32, thì bạn sẽ mất cơ hội kiểm soát điều đó.

Như tôi đã mô tả trong câu trả lời này auto đôi khi có thể dẫn đến những tình huống thú vị mà bạn không có ý định. Bạn phải nói auto&một cách rõ ràng là có một kiểu tham chiếu trong khi thực hiện chỉ autocó thể tạo một loại con trỏ. Điều này có thể dẫn đến sự nhầm lẫn bằng cách bỏ qua tất cả các công cụ xác định cùng nhau, dẫn đến một bản sao của tài liệu tham khảo thay vì một tài liệu tham khảo thực tế.

Một ví dụ khó chịu khác:

for (auto i = 0; i < s.size(); ++i)

tạo một cảnh báo ( comparison between signed and unsigned integer expressions [-Wsign-compare]), vì ilà một int đã ký. Để tránh điều này, bạn cần phải viết ví dụ

for (auto i = 0U; i < s.size(); ++i)

hoặc có lẽ tốt hơn:

for (auto i = 0ULL; i < s.size(); ++i)

Tôi nghĩ autolà tốt khi được sử dụng trong một bối cảnh cục bộ, nơi người đọc dễ dàng & rõ ràng có thể khấu trừ loại của nó, hoặc tài liệu tốt với một nhận xét về loại của nó hoặc một tên suy ra loại thực tế. Những người không hiểu làm thế nào nó hoạt động có thể đưa nó theo những cách sai, như sử dụng nó thay vì templatehoặc tương tự. Dưới đây là một số trường hợp sử dụng tốt và xấu theo ý kiến ​​của tôi.

void test (const int & a)
{
    // b is not const
    // b is not a reference

    auto b = a;

    // b type is decided by the compiler based on value of a
    // a is int
}

Sử dụng tốt

Lặp đi lặp lại

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int> v();

..

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int>::iterator it = v.begin();

// VS

auto vi = v.begin();

Chức năng con trỏ

int test (ClassWithLongName1 a, ClassWithLongName2 b, int c)
{
    ..
}

..

int (*fp)(ClassWithLongName1, ClassWithLongName2, int) = test;

// VS

auto *f = test;

Sử dụng xấu

Dòng dữ liệu

auto input = "";

..

auto output = test(input);

Chữ ký chức năng

auto test (auto a, auto b, auto c)
{
    ..
}

Trường hợp tầm thường

for(auto i = 0; i < 100; i++)
{
    ..
}

Tôi ngạc nhiên không ai đề cập đến điều này, nhưng giả sử bạn đang tính giai thừa của một cái gì đó:

#include <iostream>
using namespace std;

int main() {
    auto n = 40;
    auto factorial = 1;

    for(int i = 1; i <=n; ++i)
    {
        factorial *= i;
    }

    cout << "Factorial of " << n << " = " << factorial <<endl;   
    cout << "Size of factorial: " << sizeof(factorial) << endl; 
    return 0;
}

Mã này sẽ xuất ra điều này:

Factorial of 40 = 0
Size of factorial: 4

Đó chắc chắn không phải là kết quả mong đợi. Điều đó xảy ra bởi vì autosuy ra loại giai thừa biến intvì nó được gán cho 1.