Pourquoi std :: ssize () est-il introduit dans C ++ 20?

C ++ 20 a introduit lestd::ssize() fonction gratuite comme ci-dessous:

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

Une implémentation possible semble utiliser static_cast, pour convertir la valeur de retour de la size()fonction membre de cl ass C en son équivalent signé.

Depuis le size() fonction membre de C renvoie toujours des valeurs non négatives, pourquoi quelqu'un voudrait-il les stocker dans des variables signées? Au cas où on le voudrait vraiment, c'est simple static_cast.

Pourquoi est std::ssize()introduit dans C ++ 20?

La justification est décrite dans cet article . Une citation:

Lorsque span a été adopté dans C ++ 17, il a utilisé un entier signé à la fois comme index et comme taille. C'était en partie pour permettre l'utilisation de "-1" comme valeur sentinelle pour indiquer un type dont la taille n'était pas connue au moment de la compilation. Mais avoir un conteneur STL dont la fonction size () retournait une valeur signée était problématique, donc P1089 a été introduit pour "résoudre" le problème. Il a reçu le soutien de la majorité, mais pas la marge de 2 contre 1 nécessaire au consensus.

Ce papier, P1227, était une proposition d'ajouter des fonctions non-membres std :: ssize et membre ssize (). L'inclusion de ceux-ci rendrait certains codes beaucoup plus simples et permettrait d'éviter les non-signés indésirables dans les calculs de taille. L'idée était que la résistance à P1089 diminuerait si ssize () était disponible pour tous les conteneurs, à la fois via std :: ssize () et en tant que fonctions membres.

Volé gratuitement à Eric Niebler:

'Unsigned types signal that a negative index/size is not sane'était la sagesse dominante lors de la conception initiale de la STL. Mais logiquement, le décompte des choses n'a pas besoin d'être positif. Je peux vouloir garder un compte dans un entier signé pour indiquer le nombre d'éléments ajoutés ou supprimés d'une collection. Ensuite, je voudrais combiner cela avec la taille de la collection. Si la taille de la collection n'est pas signée, je suis maintenant obligé de mélanger l'arithmétique signée et non signée, qui est une ferme de bogues. Les compilateurs avertissent à ce sujet, mais comme la conception de la STL force à peu près les programmeurs dans cette situation, l'avertissement est si courant que la plupart des gens l'éteignent. C'est dommage car cela cache de vrais bugs.

L'utilisation d'entiers non signés dans les interfaces n'est pas l'avantage que beaucoup de gens pensent que c'est. Si par accident un utilisateur transmet un nombre légèrement négatif à l'API, il devient soudainement un nombre positif énorme. Si l'API avait pris le nombre comme signé, elle pouvait alors détecter la situation en affirmant que le nombre était supérieur ou égal à zéro.

Si nous limitons notre utilisation des entiers non signés au twiddling de bits (par exemple, les masques) et utilisons des entiers signés partout ailleurs, les bogues sont moins susceptibles de se produire et plus faciles à détecter lorsqu'ils surviennent.