1 Востаннє редагувалося wander (10.11.2019 00:48:50)

Тема: Метод std::vector::at( )

В якийсь момент, пишучи черговий код-пустишку (чим ж ще зайнятися у вихідні =.=) мені знадобився std::vector і якби це було не дивно, але коли мені потрібно було отримати елемент з вектора я чомусь замість одразу викликати оператор [], натис на . ніби хочу викликати метод (видно машинально) і доповнювач коду моєї IDE ласкаво надав список методів вектора, де засвітився at(). І тут я задумався, а навіщо він взагалі існує? Хтось його в реальних проєктах взагалі використовував? Він, як гидке каченя, але без щасливого кінця.
Наскільки я розумію він був одразу, починаючи з першого стандарту С++ (не ARM), а отже і задумувався коли стандартна бібліотека ще розроблялась Олександром та тим другим, не пам'ятаю, як його звали.
То розробники надихалися Джавою? Чи таки був пропозал, який пропонував добавити "safe" версію оператора []?

А ви як вважаєте, повинен оператор [] кидати виключення чи варто заводити щось типу методу at(), чи краще взагалі не треба?

Подякували: leofun011

2

Re: Метод std::vector::at( )

Гадаю, просто щоб зекономити пару рядків на перевірці. Якщо ваша бібліотека містить функцію, що приймає індекс і щось робить із вектором, то вам доведеться писати спершу перевірку індексу - а at дозволяє цього не робити.

Подякували: wander, leofun012

3 Востаннє редагувалося wander (10.11.2019 11:06:51)

Re: Метод std::vector::at( )

koala написав:

Гадаю, просто щоб зекономити пару рядків на перевірці. Якщо ваша бібліотека містить функцію, що приймає індекс і щось робить із вектором, то вам доведеться писати спершу перевірку індексу - а at дозволяє цього не робити.

Гм, не знаю чи так воно лише в с++ повелося, але я зазвичай не очікую, що оператор [] викине якусь бяку, а навіть навпаки я оперую на те, що він буде максимально оптимальним і компілятор зможе застосувати максимум оптимізацій і оператор [] цьому ніяк не заважатиме.
По-друге мені здається, що вихід за межі масиву - це помилка програміста, а не виключна ситуація, чим assert не підходить? Зрештою, якщо ви переживаєте чи часом десь не нафакапили, то ж для цього придумали ЮТ.

І таки скільки разів ви користувалися саме методом at()? Бо я ніразу.

Ну, і так, він дозволяє не робити типу «лишніх» перевірок для індекса, але я б вже краще написав того assert’a ніж би кожне звернення до елемента обертав у try-catch блоки або лишався noexcept специфікатора.

4

Re: Метод std::vector::at( )

Ви не очікуєте некоректної роботи, бо ви пишете код сам-один. Коли ви пишете бібліотеку, а користуватимуться нею інші - то зайві перевірки стають потрібні.
Мені колись довелося користуватися .at у програмі, забитій страшним legacy із goto, сумішшю <string> із <cstring> і т.ін. Там іноді десь глибоко всередині того жаху народжувалися некоректні індекси, і заміна [] на at у трьох місцях та додавання try-catch вирішило кілька проблем.

Подякували: vаrіg2kо1

5

Re: Метод std::vector::at( )

koala написав:

Ви не очікуєте некоректної роботи, бо ви пишете код сам-один. Коли ви пишете бібліотеку, а користуватимуться нею інші - то зайві перевірки стають потрібні.

Ні, ну, це зрозуміло, що коли пишеш код сам-один, то можна писати що завгодно, але зазвичай це ні до чого хорошого не приводить. Коли б я писав бібліотеку, якою користувалися б інші — то зайві перевірки я б робив покриттям де треба assert'aми та ЮТ, а не випльовував би бяку. І швидше за все я б від виключень взагалі відмовився. Хоча знову ж таки все залежало б від вимог, інколи просто фізично їх туди не можна засунути.

koala написав:

Мені колись довелося користуватися .at у програмі, забитій страшним legacy із goto, сумішшю <string> із <cstring> і т.ін. Там іноді десь глибоко всередині того жаху народжувалися некоректні індекси, і заміна [] на at у трьох місцях та додавання try-catch вирішило кілька проблем.

І от знову ж таки, вам прийшлося робити ці заміни бо код який вам прийшлося супроводжувати, скажемо так, пахнув не дуже і схоже ЮТ там ніяких не було, я правий?
А якби були, то і не потрібно було б цього робити, і тим самим позбутися непотрібного оверхеду.