Dlaczego w C ++ 20 wprowadzono std :: ssize ()?

C ++ 20 wprowadził std::ssize()bezpłatną funkcję, jak poniżej:

template <class C>
    constexpr auto ssize(const C& c)
        -> std::common_type_t<std::ptrdiff_t,
                              std::make_signed_t<decltype(c.size())>>;

Wydaje się static_cast, że możliwa implementacja polega na przekształceniu wartości zwracanej size()funkcji składowej klasy C na jej podpisany odpowiednik.

Ponieważ size()funkcja składowa C zawsze zwraca wartości nieujemne, dlaczego ktoś miałby chcieć przechowywać je w podpisanych zmiennych? Na wypadek, gdyby ktoś naprawdę chciał, jest to prosta sprawa static_cast.

Dlaczego std::ssize()wprowadzono w C ++ 20?

Uzasadnienie zostało opisane w tym artykule . Cytat:

Kiedy span został przyjęty do C ++ 17, używał liczby całkowitej ze znakiem zarówno jako indeksu, jak i rozmiaru. Częściowo miało to pozwolić na użycie „-1” jako wartości wartowniczej w celu wskazania typu, którego rozmiar nie był znany w czasie kompilacji. Jednak posiadanie kontenera STL, którego funkcja size () zwracała wartość ze znakiem, było problematyczne, dlatego wprowadzono P1089, aby „naprawić” problem. Otrzymał poparcie większości, ale nie margines 2 do 1 potrzebny do osiągnięcia konsensusu.

Ten dokument, P1227, był propozycją dodania nie-składowych funkcji std :: ssize i składowych ssize (). Włączenie ich uczyniłoby pewien kod znacznie prostszym i pozwoliłoby na uniknięcie niechcianego braku znaku w obliczeniach rozmiaru. Pomysł polegał na tym, że odporność na P1089 zmniejszyłaby się, gdyby funkcja ssize () była dostępna dla wszystkich kontenerów, zarówno za pośrednictwem std :: ssize (), jak i jako funkcje składowe.

Nieodpłatnie skradzione Ericowi Nieblerowi:

'Unsigned types signal that a negative index/size is not sane'była dominującą mądrością przy projektowaniu STL. Ale logicznie rzecz biorąc, liczba rzeczy nie musi być pozytywna. Mogę chcieć zachować liczbę w podpisanej liczbie całkowitej, aby oznaczyć liczbę elementów dodanych lub usuniętych z kolekcji. Wtedy chciałbym to połączyć z rozmiarem kolekcji. Jeśli rozmiar kolekcji jest bez znaku, teraz jestem zmuszony mieszać arytmetykę ze znakiem i bez znaku, co jest farmą błędów. Kompilatory ostrzegają przed tym, ale ponieważ projekt STL prawie zmusza programistów do takiej sytuacji, ostrzeżenie jest tak powszechne, że większość ludzi je wyłącza. Szkoda, bo to ukrywa prawdziwe błędy.

Używanie unsigned ints w interfejsach nie jest dobrodziejstwem, które wielu ludzi myśli, że jest. Jeśli przypadkowo użytkownik przekaże do API nieznacznie ujemną liczbę, nagle stanie się ona dużą liczbą dodatnią. Gdyby interfejs API wziął numer jako podpisany, może wykryć sytuację, stwierdzając, że liczba jest większa lub równa zero.

Jeśli ograniczymy użycie niepodpisanych intów do bitowego fałszowania (np. Masek) i użyjemy znaków int ze znakiem wszędzie indziej, prawdopodobieństwo wystąpienia błędów jest mniejsze i łatwiejsze do wykrycia, kiedy się pojawią.