vector :: at vs. vector :: operator []

Я знаю, що at()це повільніше, ніж []через перевірку меж, що також обговорюється в подібних питаннях, таких як C ++ Vector at / [] оператор швидкість або :: std :: vector :: at () vs operator [] << дивовижні результати !! У 5-10 разів повільніше / швидше! . Я просто не розумію, для чого at()метод хороший.

Якщо у мене є простий вектор, подібний до цього: std::vector<int> v(10);і я вирішую отримати доступ до його елементів, використовуючи at()замість того, []щоб мати ситуацію, коли у мене є індекс, iі я не впевнений, що він знаходиться у векторах, це змушує мене обернути його за допомогою try-catch блок :

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

хоча я можу зробити таку саму поведінку, використовуючи size()та перевіряючи індекс самостійно, що здається мені простішим та набагато зручнішим:

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

Тож моє запитання:
Які переваги використання vector :: at over vector :: operator [] ?
Коли слід використовувати оператор vector :: at замість vector :: size + vector :: [] ?

Я б сказав, що винятки, які vector::at()кидає, насправді не призначені для охоплення безпосередньо оточуючим кодом. Вони в основному корисні для лову помилок у коді. Якщо вам потрібно перевірити обмеження під час виконання, оскільки, наприклад, індекс походить від введення користувачем, вам справді найкраще запропонувати ifоператор. Отже, підсумовуючи, розробіть свій код з тим наміром, що vector::at()ніколи не призведе до винятку, так що якщо це станеться, і ваша програма перерветься, це ознака помилки. (точно як assert())

це змушує мене обернути його блоком try-catch

Ні, це не так (блок try / catch може бути вище). Це корисно, коли ви хочете, щоб було створено виняток, а не ваша програма для введення невизначеної сфери поведінки.

Я погоджуюсь, що більшість поза межами доступу до векторів є помилкою програміста (у цьому випадку вам слід скористатися, assertщоб виявити ці помилки легше; більшість налагоджувальних версій стандартних бібліотек роблять це автоматично за вас). Ви не хочете використовувати винятки, які можна проковтнути вище, щоб повідомити про помилки програміста: ви хочете мати можливість виправити помилку .

Оскільки навряд чи доступ до вектора за межами межі є частиною звичайного потоку програм (у такому випадку ви маєте рацію: попередньо перевірте, sizeзамість того, щоб пускати виняток), я погоджуюсь з вашою діагностикою: atє по суті марним.

Які переваги використання оператора vector :: at over vector :: []? Коли слід використовувати оператор vector :: at замість vector :: size + vector :: []?

Важливим моментом тут є те, що винятки дозволяють відокремлювати звичайний потік коду від логіки обробки помилок, і один блок catch може обробляти проблеми, що генеруються з будь-якого з незліченних сайтів кидка, навіть якщо розкидані глибоко в межах викликів функцій. Отже, це не те, що at()для одноразового використання обов’язково простіше, але іноді це стає простішим - і менш заплутаним для звичайної логіки - коли у вас є багато індексів для перевірки.

Також примітно, що в деяких типах коду індекс збільшується складними способами і постійно використовується для пошуку масиву. У таких випадках набагато легше забезпечити правильну перевірку використання at().

Як приклад у реальному світі, я маю код, який символізує С ++ на лексичні елементи, а потім інший код, який переміщує індекс над вектором лексем. Залежно від того, що трапилось, я можу збільшити та перевірити наступний елемент, як у:

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

У такій ситуації дуже важко перевірити, чи неправильно ви досягли кінця введення, оскільки це дуже залежить від точних виявлених токенів. Явна перевірка в кожній точці використання болюча, і є набагато більше місця для помилок програміста, оскільки збільшуються до / після збільшення, зміщення в місці використання, помилкові міркування щодо продовження дійсності деяких попередніх тестів тощо.

at може бути зрозумілішим, якщо у вас є вказівник на вектор:

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

Окрім продуктивності, першою з них є простіший і зрозуміліший код.

По-перше, не вказано, повільніше at()чи operator[]повільніше. Коли помилок меж немає, я очікував би, що вони мають приблизно однакову швидкість, принаймні в налагоджувальних збірках. Різниця полягає в тому at(), що точно вказується, що відбуватиметься, є помилка меж (виняток), де, як і у випадку operator[], це невизначена поведінка - збій у всіх використовуваних мною системах (g ++ та VC ++), принаймні коли використовуються звичайні прапорці налагодження. (Інша відмінність полягає в тому, що як тільки я впевнений у своєму коді, я можу отримати значне збільшення швидкості operator[] , вимкнувши налагодження. Якщо це вимагає продуктивність - я б не робив цього, якщо це не було потрібно.)

На практиці at()це рідко доречно. Якщо контекст такий, що ви знаєте, що індекс може бути недійсним, ви, мабуть, хочете явний тест (наприклад, повернути значення за замовчуванням або щось інше), і якщо ви знаєте, що він не може бути недійсним, ви хочете перервати (і якщо Ви не знаєте, може це бути недійсним чи ні, я б запропонував точніше вказати інтерфейс вашої функції). Однак є кілька винятків, коли недійсний індекс може виникнути в результаті аналізу даних користувача, і помилка повинна призвести до переривання всього запиту (але не призвести до збою сервера); у таких випадках підходить виняток, at()який зробить це за вас.

Вся суть використання винятків полягає в тому, що ваш код обробки помилок може бути далі.

У цьому конкретному випадку введення користувача справді є гарним прикладом. Уявіть, що ви хочете семантично проаналізувати структуру даних XML, яка використовує індекси для посилання на якийсь ресурс, який ви внутрішньо зберігаєте в std::vector. Тепер дерево XML є деревом, тому, напевно, ви хочете використовувати рекурсію для його аналізу. В глибині душі в рекурсії може бути порушення прав доступу автором файлу XML. У цьому випадку зазвичай потрібно вийти з усіх рівнів рекурсії і просто відхилити весь файл (або будь-яку «грубішу» структуру). Тут де-небудь пригодиться. Ви можете просто написати код аналізу так, ніби файл справжній. Бібліотечний код подбає про виявлення помилок, і ви можете просто вловити помилку на грубому рівні.

Крім того, інші контейнери, наприклад std::map, також мають std::map::atсемантику, яка має дещо іншу семантику, ніж std::map::operator[]: at, може використовуватися на карті const, тоді як operator[]не може. Тепер, якщо ви хочете написати агностичний код контейнера, наприклад, щось, що може мати справу з будь-яким const std::vector<T>&або const std::map<std::size_t, T>&, ContainerType::atбуде вашою обраною зброєю.

Однак усі ці випадки зазвичай виникають при обробці якогось неперевіреного введення даних. Якщо ви впевнені у своєму дійсному діапазоні, як це зазвичай має бути, ви зазвичай можете використовувати operator[], але ще краще, ітератори з begin()та end().

Згідно з цією статтею, якщо не брати до уваги продуктивність, вона не має жодної різниці у використанні atабо operator[]лише в тому випадку, якщо доступ гарантовано буде в межах розміру вектора. В іншому випадку, якщо доступ базується лише на потужності вектора, використовувати його безпечніше at.

Примітка: Схоже, деякі нові люди проти цієї відповіді голосують, не маючи ввічливості сказати, що не так. Нижче відповідь правильна і її можна перевірити тут .

Різниця насправді є лише одна: atперевіряє межі, а operator[]не робить. Це стосується збірок налагодження, а також збірок випусків, і це дуже добре визначено стандартами. Це все так просто.

Це робить atметод повільнішим, але це також дуже погана порада не використовувати at. Ви повинні дивитись на абсолютні числа, а не на відносні. Я можу сміливо переконатись, що більша частина вашого коду робить більш дорогі операції, ніж at. Особисто я намагаюся використовувати, atтому що не хочу, щоб неприємна помилка створювала невизначену поведінку та підкрадалася до виробництва.