vector :: at so với vector :: operator []

Tôi biết điều đó at()chậm hơn so với []việc kiểm tra ranh giới của nó, điều này cũng được thảo luận trong các câu hỏi tương tự như C ++ Vector ở tốc độ toán tử / [] hoặc :: std :: vector :: at () vs operator [] << kết quả đáng ngạc nhiên !! Chậm hơn 5 đến 10 lần / nhanh hơn! . Tôi chỉ không hiểu at()phương pháp này tốt để làm gì.

Nếu tôi có một vectơ đơn giản như thế này: std::vector<int> v(10);và tôi quyết định truy cập các phần tử của nó bằng cách sử dụng at()thay vì []trong trường hợp tôi có chỉ mục ivà tôi không chắc liệu nó có bị giới hạn trong vectơ hay không, nó buộc tôi phải bọc nó bằng try-catch khối :

try
{
    v.at(i) = 2;
}
catch (std::out_of_range& oor)
{
    ...
}

mặc dù tôi có thể thực hiện hành vi tương tự bằng cách tự mình sử dụng size()và kiểm tra chỉ mục, điều này có vẻ dễ dàng và thuận tiện hơn nhiều đối với tôi:

if (i < v.size())
    v[i] = 2;

Vì vậy, câu hỏi của tôi là:
Lợi ích của việc sử dụng vector :: at over vector :: operator [] là gì?
Khi nào tôi nên sử dụng vector :: at thay vì vector :: size + vector :: operator [] ?

Tôi muốn nói rằng các trường hợp ngoại lệ vector::at()ném không thực sự có ý định bị bắt bởi mã xung quanh ngay lập tức. Chúng chủ yếu hữu ích để bắt lỗi trong mã của bạn. Nếu bạn cần kiểm tra giới hạn trong thời gian chạy vì ví dụ: chỉ mục đến từ đầu vào của người dùng, bạn thực sự nên sử dụng một ifcâu lệnh. Vì vậy, tóm lại, hãy thiết kế mã của bạn với ý định vector::at()không bao giờ có ngoại lệ, để nếu nó xảy ra và chương trình của bạn ngừng hoạt động, đó là dấu hiệu của một lỗi. (giống như một assert())

nó buộc tôi phải bọc nó bằng khối try-catch

Không, không có (khối try / catch có thể ngược dòng). Nó rất hữu ích khi bạn muốn một ngoại lệ được đưa ra thay vì chương trình của bạn vào vùng hành vi không xác định.

Tôi đồng ý rằng hầu hết các truy cập ngoài giới hạn vào vectơ là lỗi của lập trình viên (trong trường hợp đó, bạn nên sử dụng assertđể xác định các lỗi đó dễ dàng hơn; hầu hết các phiên bản gỡ lỗi của thư viện tiêu chuẩn tự động thực hiện việc này cho bạn). Bạn không muốn sử dụng các ngoại lệ có thể bị nuốt ngược dòng để báo cáo lỗi của lập trình viên: bạn muốn có thể sửa lỗi .

Vì không chắc rằng việc truy cập ngoài giới hạn vào một vectơ là một phần của luồng chương trình bình thường (trong trường hợp đúng như vậy, bạn nói đúng: hãy kiểm tra trước sizethay vì để ngoại lệ nổi lên), tôi đồng ý với chẩn đoán của bạn: atvề bản chất là vô dụng.

Lợi ích của việc sử dụng vector :: at over vector :: operator [] là gì? Khi nào tôi nên sử dụng vector :: at thay vì vector :: size + vector :: operator []?

Điểm quan trọng ở đây là các ngoại lệ cho phép tách dòng mã bình thường khỏi logic xử lý lỗi và một khối bắt duy nhất có thể xử lý các vấn đề được tạo ra từ bất kỳ trang web ném nào, ngay cả khi nằm rải rác sâu bên trong các lệnh gọi hàm. Vì vậy, điều đó không at()nhất thiết là dễ dàng hơn cho một lần sử dụng, nhưng đôi khi nó trở nên dễ dàng hơn - và ít gây xáo trộn hơn đối với logic trường hợp bình thường - khi bạn có nhiều chỉ mục để xác thực.

Cũng cần lưu ý rằng trong một số loại mã, một chỉ mục đang được tăng dần theo những cách phức tạp và liên tục được sử dụng để tra cứu một mảng. Trong những trường hợp như vậy, sẽ dễ dàng hơn nhiều để đảm bảo kiểm tra chính xác bằng cách sử dụng at().

Như một ví dụ trong thế giới thực, tôi có mã mã hóa C ++ thành các phần tử từ vựng, sau đó mã khác di chuyển một chỉ mục qua vectơ mã thông báo. Tùy thuộc vào những gì gặp phải, tôi có thể muốn tăng và kiểm tra phần tử tiếp theo, như trong:

if (token.at(i) == Token::Keyword_Enum)
{
    ASSERT_EQ(tokens.at(++i), Token::Idn);
    if (tokens.at(++i) == Left_Brace)
        ...
    or whatever

Trong loại tình huống này, rất khó để kiểm tra xem bạn đã đến cuối đầu vào một cách không thích hợp hay chưa vì điều đó phụ thuộc rất nhiều vào các mã thông báo chính xác gặp phải. Kiểm tra rõ ràng tại mỗi điểm sử dụng là khó khăn và có nhiều chỗ cho lỗi của lập trình viên hơn như gia số trước / sau, hiệu số tại điểm sử dụng, lý luận sai lầm về tính hợp lệ liên tục của một số thử nghiệm trước đó, v.v. bắt đầu.

at có thể rõ ràng hơn nếu bạn có một con trỏ đến vectơ:

return pVector->at(n);
return (*pVector)[n];
return pVector->operator[](n);

Hiệu suất sang một bên, điều đầu tiên trong số này là mã đơn giản và rõ ràng hơn.

Đầu tiên, cho dù at()hoặc operator[]là chậm không được xác định. Khi không có lỗi giới hạn, tôi mong đợi chúng có cùng tốc độ, ít nhất là trong các bản dựng gỡ lỗi. Sự khác biệt là at()chỉ định chính xác điều gì sẽ xảy ra khi có lỗi giới hạn (một ngoại lệ), trong trường hợp operator[]đó, đó là hành vi không xác định — một sự cố trong tất cả các hệ thống tôi sử dụng (g ++ và VC ++), ít nhất là khi cờ gỡ lỗi bình thường được sử dụng. (Một điểm khác biệt nữa là khi tôi chắc chắn về mã của mình, tôi có thể tăng tốc độ đáng kể operator[] bằng cách tắt gỡ lỗi. Nếu hiệu suất yêu cầu - tôi sẽ không làm điều đó trừ khi cần thiết.)

Trong thực tế, at()hiếm khi thích hợp. Nếu ngữ cảnh mà bạn biết rằng chỉ mục có thể không hợp lệ, bạn có thể muốn kiểm tra rõ ràng (ví dụ: trả về giá trị mặc định hoặc thứ gì đó) và nếu bạn biết rằng nó không thể không hợp lệ, bạn muốn hủy bỏ (và nếu bạn không biết liệu nó có thể không hợp lệ hay không, tôi khuyên bạn nên chỉ định giao diện chức năng của mình chính xác hơn). Tuy nhiên, có một số trường hợp ngoại lệ, trong đó chỉ mục không hợp lệ có thể do phân tích dữ liệu người dùng và lỗi sẽ gây ra việc hủy bỏ toàn bộ yêu cầu (nhưng không làm cho máy chủ hoạt động); trong những trường hợp như vậy, một ngoại lệ là phù hợp và at()sẽ làm điều đó cho bạn.

Toàn bộ điểm của việc sử dụng ngoại lệ là mã xử lý lỗi của bạn có thể xa hơn.

Trong trường hợp cụ thể này, đầu vào của người dùng thực sự là một ví dụ điển hình. Hãy tưởng tượng bạn muốn phân tích ngữ nghĩa một cấu trúc dữ liệu XML sử dụng các chỉ mục để tham chiếu đến một số loại tài nguyên mà bạn lưu trữ nội bộ trong a std::vector. Bây giờ cây XML là một cây, vì vậy bạn có thể muốn sử dụng đệ quy để phân tích nó. Sâu xa hơn, trong đệ quy, có thể có vi phạm quyền truy cập bởi người viết tệp XML. Trong trường hợp đó, bạn thường muốn loại bỏ tất cả các cấp độ đệ quy và chỉ từ chối toàn bộ tệp (hoặc bất kỳ loại cấu trúc "thô hơn" nào). Đây là nơi có ích. Bạn chỉ có thể viết mã phân tích như thể tệp hợp lệ. Mã thư viện sẽ đảm nhận việc phát hiện lỗi và bạn chỉ có thể bắt lỗi ở cấp độ thô.

Ngoài ra, các vùng chứa khác, chẳng hạn như std::map, cũng có std::map::atngữ nghĩa hơi khác với std::map::operator[]: at có thể được sử dụng trên bản đồ const, trong khi operator[]không thể. Bây giờ, nếu bạn muốn viết mã bất khả tri vùng chứa, như một thứ gì đó có thể giải quyếtconst std::vector<T>& hoặc const std::map<std::size_t, T>&, ContainerType::atsẽ là vũ khí bạn lựa chọn.

Tuy nhiên, tất cả các trường hợp này thường xuất hiện khi xử lý một số loại đầu vào dữ liệu chưa được xác thực. Nếu bạn chắc chắn về phạm vi hợp lệ của mình, như thường lệ, bạn thường có thể sử dụng operator[], nhưng tốt hơn, các trình vòng lặp với begin()và end().

Theo này bài viết, thực hiện sang một bên, nó không thực hiện bất kỳ sự khác biệt để sử dụng athoặc operator[], chỉ khi truy cập được đảm bảo là trong kích thước của vector. Ngược lại, nếu truy cập chỉ dựa trên dung lượng của vector thì sẽ an toàn hơn khi sử dụng at.

Lưu ý: Có vẻ như một số người mới đang phản đối câu trả lời này mà không cần lịch sự cho biết điều gì sai. Câu trả lời dưới đây là chính xác và có thể được xác minh tại đây .

Thực sự chỉ có một sự khác biệt: atkiểm tra giới hạn trong khi operator[]thì không. Điều này áp dụng cho các bản dựng gỡ lỗi cũng như các bản dựng phát hành và điều này được quy định rất rõ bởi các tiêu chuẩn. Nó đơn giản mà.

Điều này làm cho atmột phương pháp chậm hơn nhưng cũng thực sự không nên sử dụng at. Bạn phải nhìn vào số tuyệt đối, không phải số tương đối. Tôi có thể đặt cược một cách an toàn rằng hầu hết mã của bạn đang thực hiện các hoạt động tốn kém hơn at. Cá nhân tôi cố gắng sử dụng atvì tôi không muốn một lỗi khó chịu tạo ra hành vi không xác định và lẻn vào sản xuất.