wektor :: at a wektor :: operator []

Wiem, że at()jest to wolniejsze niż []ze względu na sprawdzanie granic, które jest również omawiane w podobnych pytaniach, takich jak C ++ Vector at / [] operator speed lub :: std :: vector :: at () vs operator [] << zaskakujące wyniki !! 5 do 10 razy wolniej / szybciej! . Po prostu nie rozumiem, do czego ta at()metoda jest dobra.

Jeśli mam prosty wektor taki jak ten: std::vector<int> v(10);i decyduję się uzyskać dostęp do jego elementów za pomocą at()zamiast []w sytuacji, gdy mam indeks ii nie jestem pewien, czy jest w granicach wektorów, zmusza mnie to do owinięcia go try-catch blok :

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

chociaż jestem w stanie uzyskać to samo zachowanie, używając size()i sprawdzając indeks samodzielnie, co wydaje mi się łatwiejsze i znacznie wygodniejsze:

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

Więc moje pytanie brzmi:
jakie są zalety używania vector :: at over vector :: operator [] ?
Kiedy powinienem używać vector :: at zamiast vector :: size + vector :: operator [] ?

Powiedziałbym, że wyjątki, które vector::at()rzucają, nie są tak naprawdę przeznaczone do przechwytywania przez bezpośrednio otaczający kod. Są one głównie przydatne do wyłapywania błędów w kodzie. Jeśli potrzebujesz sprawdzić ograniczenia w czasie wykonywania, ponieważ np. Indeks pochodzi z danych wejściowych użytkownika, rzeczywiście najlepiej będzie, jeśli skorzystasz z ifinstrukcji. Podsumowując, zaprojektuj swój kod z zamiarem, vector::at()który nigdy nie zgłosi wyjątku, więc jeśli tak się stanie, a program zostanie przerwany, jest to oznaka błędu. (tak jak assert())

zmusza mnie do owinięcia go blokiem try-catch

Nie, nie (blok try / catch może znajdować się powyżej). Jest to przydatne, gdy chcesz, aby wyjątek został wyrzucony, a nie program, aby wejść w niezdefiniowaną dziedzinę zachowania.

Zgadzam się, że większość dostępów poza granicami do wektorów jest błędem programisty (w takim przypadku powinieneś użyć assertdo łatwiejszego zlokalizowania tych błędów; większość wersji bibliotek standardowych do debugowania robi to automatycznie). Nie chcesz używać wyjątków, które można połknąć w celu zgłaszania błędów programisty: chcesz mieć możliwość naprawienia błędu .

Ponieważ jest mało prawdopodobne, aby dostęp do wektora poza granicami był częścią normalnego przebiegu programu (w takim przypadku masz rację: sprawdź wcześniej za pomocą size zamiast pozwolić, aby wyjątek się pojawił), zgadzam się z twoją diagnostyką: atjest zasadniczo bezużyteczna.

Jakie są zalety używania vector :: at over vector :: operator []? Kiedy powinienem używać vector :: at zamiast vector :: size + vector :: operator []?

Ważną kwestią jest tutaj to, że wyjątki pozwalają na oddzielenie normalnego przepływu kodu od logiki obsługi błędów, a pojedynczy blok catch może obsługiwać problemy generowane przez niezliczone miejsca przesyłania, nawet jeśli są rozproszone głęboko w wywołaniach funkcji. Tak więc at()niekoniecznie jest to łatwiejsze do pojedynczego użycia, ale czasami staje się łatwiejsze - i mniej zaciemniające logikę normalnych przypadków - gdy masz dużo indeksowania do sprawdzenia.

Warto również zauważyć, że w niektórych typach kodu indeks jest zwiększany w złożony sposób i stale używany do wyszukiwania tablicy. W takich przypadkach o wiele łatwiej jest zapewnić prawidłowe sprawdzenia za pomocą at().

Jako przykład ze świata rzeczywistego mam kod, który tokenizuje C ++ na elementy leksykalne, a następnie inny kod, który przesuwa indeks nad wektorem tokenów. W zależności od tego, co napotkano, mogę chcieć zwiększyć i sprawdzić następny element, na przykład:

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

W takiej sytuacji bardzo trudno jest sprawdzić, czy nieprawidłowo dotarłeś do końca danych wejściowych, ponieważ jest to bardzo zależne od dokładnych napotkanych tokenów. Jawne sprawdzanie w każdym punkcie użycia jest bolesne i jest znacznie więcej miejsca na błędy programisty, gdy wkraczają inkrementacje przed / po, przesunięcia w miejscu użycia, błędne rozumowanie o ciągłej ważności niektórych wcześniejszych testów itp.

at może być wyraźniejsze, jeśli masz wskaźnik do wektora:

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

Pomijając wydajność, pierwszym z nich jest prostszy i jaśniejszy kod.

Po pierwsze, czy at()czy operator[]jest wolniejsze nie jest określona. Gdy nie ma błędu związanego z ograniczeniami, spodziewałbym się, że będą miały mniej więcej taką samą prędkość, przynajmniej w kompilacjach debugowania. Różnica polega na tym, że at()dokładnie określa, co się stanie, gdy wystąpi błąd granic (wyjątek), gdzie tak jak w przypadku operator[], jest to niezdefiniowane zachowanie - awaria we wszystkich systemach, których używam (g ++ i VC ++), przynajmniej wtedy, gdy używane są zwykłe flagi debugowania. (Inną różnicą jest to, że gdy jestem pewien swojego kodu, mogę uzyskać znaczny wzrost szybkości operator[] , wyłączając debugowanie. Jeśli wydajność tego wymaga - nie zrobiłbym tego, gdyby nie było to konieczne.)

W praktyce at()rzadko jest odpowiednie. Jeśli kontekst jest taki, że wiesz, że indeks może być nieprawidłowy, prawdopodobnie chcesz jawnego testu (np. Aby zwrócił wartość domyślną lub coś w tym rodzaju), a jeśli wiesz, że nie może być nieprawidłowy, chcesz przerwać (i jeśli nie wiesz, czy może być nieprawidłowy, czy nie, sugerowałbym dokładniejsze określenie interfejsu funkcji). Jest jednak kilka wyjątków, w których nieprawidłowy indeks może wynikać z analizy danych użytkownika, a błąd powinien spowodować przerwanie całego żądania (ale nie spowoduje wyłączenia serwera); w takich przypadkach wyjątek jest odpowiedni i at()zrobi to za Ciebie.

Cały sens używania wyjątków polega na tym, że kod obsługi błędów może być dalej.

W tym konkretnym przypadku dane wprowadzane przez użytkownika są rzeczywiście dobrym przykładem. Wyobraź sobie, że chcesz semantycznie przeanalizować strukturę danych XML, która używa indeksów do odwoływania się do jakiegoś rodzaju zasobu, który przechowujesz wewnętrznie w pliku std::vector. Teraz drzewo XML jest drzewem, więc prawdopodobnie chcesz użyć rekurencji do jego analizy. W głębi, w rekurencji, może wystąpić naruszenie zasad dostępu ze strony autora pliku XML. W takim przypadku zazwyczaj chcesz usunąć wszystkie poziomy rekurencji i po prostu odrzucić cały plik (lub jakąkolwiek „grubszą” strukturę). Tutaj przydaje się at. Możesz po prostu napisać kod analizy tak, jakby plik był prawidłowy. Kod biblioteki zajmie się wykrywaniem błędów i możesz po prostu wyłapać błąd na poziomie zgrubnym.

Również inne kontenery, takie jak std::map, również mają std::map::atnieco inną semantykę niż std::map::operator[]: at mogą być używane na mapie const, podczas gdy operator[]nie mogą. Teraz, jeśli chcesz napisać kod niezależny od kontenera, na przykład coś, co mogłoby sobie poradzić z jednym const std::vector<T>&lub drugim const std::map<std::size_t, T>&, ContainerType::atbyłoby twoją bronią z wyboru.

Jednak wszystkie te przypadki pojawiają się zwykle podczas obsługi jakiegoś rodzaju niezatwierdzonych danych wejściowych. Jeśli jesteś pewien swojego prawidłowego zakresu, jak zwykle powinieneś, możesz zwykle użyć operator[], ale jeszcze lepiej, iteratorów z begin()i end().

Zgodnie z tym artykułem, pomijając wydajność, nie ma znaczenia użycie atlub operator[]tylko wtedy, gdy gwarantuje się, że dostęp będzie mieścił się w rozmiarze wektora. W przeciwnym razie, jeśli dostęp jest oparty tylko na pojemności wektora, bezpieczniej jest z niego korzystać at.

Uwaga: wygląda na to, że niektórzy nowi ludzie odrzucają tę odpowiedź bez uprzejmości, by powiedzieć, co jest nie tak. Poniższa odpowiedź jest poprawna i można ją tutaj zweryfikować .

Tak naprawdę jest tylko jedna różnica: atsprawdza granice, a operator[]nie. Dotyczy to zarówno kompilacji debugowania, jak i kompilacji wydań i jest to bardzo dobrze określone przez standardy. To takie proste.

Jest atto wolniejsza metoda, ale bardzo zła rada, aby jej nie używać at. Musisz patrzeć na liczby bezwzględne, a nie względne. Mogę się bezpiecznie założyć, że większość twojego kodu wykonuje grubo droższe operacje niż at. Osobiście staram się używać, atponieważ nie chcę, aby paskudny błąd powodował niezdefiniowane zachowanie i przedostał się do produkcji.