Discussion :

[oodini]

Je voudrais faire une fonction pour initialiser une série de vecteurs (clear() + reserve()).

Pour le reserve, j'ai besoin d'une taille. En théorie, ma fonction devrait donc prendre un paramètre size_type, car c'est ce que prend la méthode reserve(). Or, le type size_type est dépendant de l'instanciation de vecteur. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

vector<int>::size_type

Or, je ne vois pas pourquoi le type définissant le nombre d'éléments d'un vecteur devrait dépendre du type des éléments contenus par ce vecteur.

C'est bien entendu de la curiosité intellectuelle, car je sais bien que je peux juste travailler avec des unsigned int...

[Klaim]

Ou avec size_t (ou std::size_t, je sais plus lequel est le vrai bon).

Il y a de l'explication dans la réponse de David Rodrigez là : http://stackoverflow.com/questions/2...-encapsulation

I would use a typedef in the class. The reason is that for std::vector, the size type is std::size_t, but if you later change the code to use a container (hand rolled) whose size type is not std::size_t redefining the typedef will be enough.

Using that typedef does not expose any detail of implementation, and it in fact helps encapsulate. The important element in the typedef is the local name, not what it is defined to be.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for ( mytype::size_type i = 0; i < myelement.size(); ++i )

In the for loop above, user code is unaware of whether size_type is a signed or unsigned type, it just works. You can change your implementation, and as long as you update the typedef the previous code will compile without signed/unsigned comparison warnings. The typedef actually helps encapsulation.

[oodini]

Histoire de poursuivre l'exercice intellectuel, size_type n'est garanti comme étant size_t que pour les conteneurs standard qui utilisent l'allocateur par défaut...

Il est étrange qu'il n'y ait pas moyen d'accéder à des membres ne dépendant pas du type des éléments sans recourir à une instanciation particulière du template.

[Klaim]

Cela dit tu peux toujours utiliser une déclaration extern template pour ne pas instantier le template immédiatement...

[Emmanuel Deloget]

vector<T,Alloc>::size_type est Alloc::size_type, qui lui même est défini comme étant un type entier non signé qui peut représenter la taille du plus gros objet dans le modèle d'allocation (quel que soit l'allocateur).

std::size_t est déclaré et défini dans <cstddef> comme étant un lien sur ::size_t (en utilisant une directive using). size_t a grosso-modo la même définition que Alloc::size_type. Du coup, A moins de développer un allocateur spécifique qui ne suivrait pas la norme (et qui donc pourrait amener un programme dans un état indéfini), on peut considérer que Alloc::size_type est std::size_t ou un autre type intégral non signé permettant de stocker au moins la même chose.

Si sizeof(Alloc::size_type) > sizeof(std::size_t) alors tous les bits en trop ne seront pas utilisés, puisque par définition, std::size_t est capable de stocker la taille maximale d'un objet alloué dans le système. Du coup, un cast vers std::size_t ne fera pas perdre d'information.

Au final, std::size_t est un candidat nécessaire et suffisant pour faire ce que tu veux faire.

[oodini]

vector<T,Alloc>::size_type est Alloc::size_type, qui lui même est défini comme étant un type entier non signé qui peut représenter la taille du plus gros objet dans le modèle d'allocation (quel que soit l'allocateur).

Mais quel rapport entre la taille du plus gros objet, et le nombre d'objets stockés, puisque manifestement, la taille de la mémoire disponible ne fait pas partie des données considérées ?

std::size_t est déclaré et défini dans <cstddef> comme étant un lien sur ::size_t (en utilisant une directive using). size_t a grosso-modo la même définition que Alloc::size_type. Du coup, A moins de développer un allocateur spécifique qui ne suivrait pas la norme (et qui donc pourrait amener un programme dans un état indéfini), on peut considérer que Alloc::size_type est std::size_t ou un autre type intégral non signé permettant de stocker au moins la même chose.

Si au final, la norme nous oblige à rester scotché à size_t, que est l'intérêt de faire un détour par Alloc::size_type ? Et pourquoi vector<>.reserve() ne prend-il pas tout simplement un paramètre de type std::size_t ?

Au final, std::size_t est un candidat nécessaire et suffisant pour faire ce que tu veux faire.

Oui, effectivement, mais ça me laisse le sentiment que le truc a été mal pensé.

[Emmanuel Deloget]

Mais quel rapport entre la taille du plus gros objet, et le nombre d'objets stockés, puisque manifestement, la taille de la mémoire disponible ne fait pas partie des données considérées ?

La taille maximale que peut prendre un vecteur est atteinte pour numeric_limits<std::size_t>::max() éléments de 1 byte (des char, par exemple).

Si au final, la norme nous oblige à rester scotché à size_t, que est l'intérêt de faire un détour par Alloc::size_type ? Et pourquoi vector<>.reserve() ne prend-il pas tout simplement un paramètre de type std::size_t ?

Rien n'empêche de mettre un Alloc::size_type plus gros que std::size_t ; du moment qu'il n'est pas plus petit, ça marchera.

Oui, effectivement, mais ça me laisse le sentiment que le truc a été mal pensé.

Ce n'est pas impossible. Je n'avais pas réfléchi à ça. En même temps, on souhaite stocker des tailles ou des nombre d'objets. La valeur est > 0 et peut être potentiellement très grande. Il y a peu de candidats viables

[3DArchi]

Salut,

vector<T,Alloc>::size_type est Alloc::size_type, qui lui même est défini comme étant un type entier non signé qui peut représenter la taille du plus gros objet dans le modèle d'allocation (quel que soit l'allocateur).

Si j'en crois ceci, c'est même plus fort :

Implementations of containers described in this International Standard are permitted to assume that their Allocator template parameter meets the following two additional requirements beyond those in Table 32.
— All instances of a given allocator type are required to be interchangeable and always compare equal to each other.
— The typedef members pointer, const_pointer, size_type, and difference_type are required to be T*,T const*, size_t, and ptrdiff_t, respectively.

Je comprends qu'un allocator::size_type doit être un size_t.

Ce n'est pas impossible. Je n'avais pas réfléchi à ça.

A mon humble avis, ce n'est que pour ne pas créer d'interdépendance puisque size_t n'est pas un type natif. Un conteneur n'est alors dépendant que de ses paramètres génériques.

[Steph_ng8]

size_t n'est pas un type natif.

Qu'est-ce que tu entends par là ?

std::size_t est déclaré et défini dans <cstddef> comme étant un lien sur ::size_t (en utilisant une directive using).

Ça ne suffit pas pour dire qu'il est natif ?
Ce symbole provient du C, si je ne m'abuse (un typedef sur unsigned int il me semble).

À moins que ça ne soit une implémentation propre au compilateur... ?

[oodini]

Rien n'empêche de mettre un Alloc::size_type plus gros que std::size_t ; du moment qu'il n'est pas plus petit, ça marchera.

Josuttis, dans The C++ Standard Library", indique, pour allocator:size_type :

"To be usable by the standard containers, this type must be equivalent to size_t"

Bref, les tailles pour les conteneurs standard sont donc forcément exprimés en size_t. Dès lors, pourquoi ce membre size_type ?

[Emmanuel Deloget]

Qu'est-ce que tu entends par là ?

C'est un type standard, mais il est quand même créé par un typedef, contrairement aux types scalaires intégraux de base (char, int, short, long, long long et les versions unsigned).

Ça ne suffit pas pour dire qu'il est natif ?
Ce symbole provient du C, si je ne m'abuse (un typedef sur unsigned int il me semble).

À moins que ça ne soit une implémentation propre au compilateur... ?

Probablement unsigned long, ou unsigned long long. Le type exact est implementation defined

[3DArchi]

Dès lors, pourquoi ce membre size_type ?

A mon humble avis, ce n'est que pour ne pas créer d'interdépendance puisque size_t n'est pas un type natif. Un conteneur n'est alors dépendant que de ses paramètres génériques.

@steph: comme dit Emmanuel, par (mon propos maladroit) type natif, je voulais dire qu'il nécessite l'inclusion d'un fichier d'en-tête déclarant le type size_t. Et je pense que c'est pour cela qu'un conteneur attend de son allocateur la définition d'un type allocator:size_type, pour éviter une dépendance supplémentaire.

@Emmanuel : pour l'article sur les droits de propriétés.

[Steph_ng8]

@Emmanuel Deloget et @3DArchi ok et merci.

[Emmanuel Deloget]

@Emmanuel : pour l'article sur les droits de propriétés.