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é.