Miałem cudowną rozmowę z kimś na temat upadkówstd::stoi. Mówiąc wprost, używastd::strtol wewnętrznie i rzuca, jeśli zgłosi błąd. Według nich jednakstd::strtol nie powinien zgłaszać błędu dla danych wejściowych"abcxyz", powodującstoi nie rzucaćstd::invalid_argument.

Po pierwsze, oto dwa programy testowane w GCC na temat zachowań tych przypadków:
strtol
stoi

Oba odnoszą sukces"123" i porażka"abc".

Szukałem w standardzie więcej informacji:

§ 21.5

Throws: invalid_argument if strtol, strtoul, strtoll, or strtoull reports that  
no conversion could be performed. Throws out_of_range if the converted value is  
outside the range of representable values for the return type.

To podsumowuje zachowanie polegania nastrtol. A teraz costrtol? Znalazłem to w projekcie C11:

§7.22.1.4

If the subject sequence is empty or does not have the expected form, no  
conversion is performed; the value of nptr is stored in the object  
pointed to by endptr, provided that endptr is not a null pointer.

Biorąc pod uwagę sytuację przejścia"abc", standard C tego wymaganptr, który wskazuje na początek ciągu, byłby przechowywany wendptr, wskaźnik przeszedł. Wydaje się to zgodne z testem. Należy również zwrócić 0, jak stwierdzono w tym:

§7.22.1.4

If no conversion could be performed, zero is returned.

Poprzednie odniesienie mówiło, że żadna konwersja nie zostanie wykonana, więc musi zwrócić 0. Te warunki są teraz zgodne ze standardem C ++ 11 dlastoi rzucaniestd::invalid_argument.

Wynik tego ma dla mnie znaczenie, ponieważ nie chcę się kręcić, polecającstoi jako lepsza alternatywa dla innych metod konwersji ciągów na int lub używania ich samodzielnie, jakby działało tak, jak się tego spodziewałeś, jeśli nie przechwytuje tekstu jako nieprawidłowej konwersji.

Więc po tym wszystkim, gdzieś się pomyliłem? Wydaje mi się, że mam dobry dowód na to, że wyjątek został rzucony. Czy mój dowód jest ważny?std::stoi nie gwarantuję rzucenia tego wyjątku, gdy zostanie podany"abc"?