Y a-t-il une différence entre size_t et container::size_type? Ce que je comprends est size_t est plus générique et peut être utilisé pour size_type s.'size_t' vs 'container :: size_type'
Mais est-ce que container::size_type est optimisé pour des types spécifiques de conteneurs?
Les conteneurs standards définissent size_type comme un typedef à Allocator::size_type (allocateur est un paramètre de modèle), qui est pour std::allocator<T>::size_typetypiquement définie comme size_t (ou d'un type compatible). Donc, pour le cas standard, ils sont identiques. Toutefois, si vous utilisez un allocateur personnalisé, un type sous-jacent différent peut être utilisé. Donc, container::size_type est préférable pour une généralité maximale.
Pour std::[w]string, std::[w]string::size_type est égal à std::allocator<T>::size_type, ce qui correspond à std::size_t. Pour les autres conteneurs, il s'agit d'un type entier non signé défini par l'implémentation.
Parfois, il est utile d'avoir le type exact, par exemple, on sait où le type s'enroule (comme, à UINT_MAX) afin que l'on puisse en faire usage. Ou pour les modèles, où vous devez vraiment passer deux types identiques aux modèles de classe/fonction.
Souvent, je trouve que j'utilise size_t pour la brièveté ou les itérateurs de toute façon. Dans le code générique, puisque vous ne savez généralement pas avec quelle instance de conteneur votre modèle est utilisé et quelle taille ont ces conteneurs, vous devrez utiliser le typedef Container::size_type si vous avez besoin de stocker la taille des conteneurs.
size_t est défini comme étant du type utilisé pour la taille d'un objet et est dépendant de la plateforme .container::size_type est le type utilisé pour le nombre d'éléments dans le conteneur et dépendant du conteneur.Tous std conteneurs utilisent size_t comme size_type, mais chaque fournisseur de bibliothèque indépendante choisit un type qu'il juge approprié pour son récipient.
Si vous regardez qt, vous constaterez que les conteneurs Qt size_type dépendent de la version. Dans Qt3, il était unsigned int et dans Qt4 il a été changé en int.
Je trouve un peu étrange d'avoir la taille d'un objet exprimé en int. Pourrions-nous avoir une taille négative pour un conteneur? –
@MihaiTodor: il n'est pas inhabituel pour les gens d'utiliser des types signés pour tout, je suppose que Qt fait de même. La raison en est que les opérations mixtes (en particulier les comparaisons) sont une telle zone sinistrée que beaucoup de gens préfèrent éviter d'utiliser des types non signés pour les numéros, plutôt que d'avoir à traiter et/ou éviter les opérations mixtes. Juste parce que les types non signés ne peuvent pas exprimer des nombres négatifs, cela ne signifie pas que vous devez les utiliser pour des nombres qui ne peuvent pas être négatifs :-) J'avoue que je suis surpris que ce soit 'int' plutôt que' ssize_t', ' int' est un peu petit. –
@Steve Oui, vous avez un point. Merci. –
Pouvez-vous clarifier cette réponse? J'ai repensé au projet de normes aussi loin que 'N1804' et je ne vois aucune relation entre' Allocator :: size_type' et 'size_type'. Un rapide coup d'oeil sur libstdC++ ne montre rien de similaire à cela non plus. –
@ShafikYaghmour, Donc, cette réponse est légèrement dépassée, mais pour maximiser la portabilité, je pense que le conseil est toujours bon: C++ 03 spécifié "Tableau 32: taille_type: un type qui peut représenter la taille de l'objet le plus important dans le modèle d'allocation. " À l'époque, 'size_t' était l'implémentation pratique de ces contraintes. Cependant, en C++ 11, il est maintenant défini essentiellement comme: 'std :: make_unsigned :: type' par défaut. Ce qui dans la pratique, sera probablement le même ou compatible avec 'size_t'. –
SOYEZ la réponse est incorrecte .... voir http: // stackoverflow.com/questions/4849678/c-for-loop-size-type-vs-size-t TL: DR: les allocateurs size_type doivent être size_t et en C++ 17 size_type sera obsolète tel quel. – user3063349