 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Michel Michaud
Guest
|
 Posted: Tue Jan 27, 2004 6:36 am Post subject: size_t vs vector::size_type |
 |
|
Il me semble que James a déjà démontré par des articles de la norme,
que vector<>::size_type ne peut pas être différent de size_t. Je me
trompe ?
Est-il alors « correct » d'écrire :
vector<TypeQuelconque> v;
...
for (size_t i= 0; i != v.size(); ++i)
...
Je trouve difficile d'introduire vector::size_type rapidement.
Surtout lorsque les vecteurs contiennent des types personnels :
for (vector<TypeQuelconque>::size_type i= 0; i != v.size(); ++i)
C'est terriblement lourd, il me semble. Au point où il apparaît
qu'un typedef (pour vector<TypeQuelconque>::size_type) serait très
utile. Mais est-ce raisonnable de faire un typedef pour chaque type
de vector (dans bien des programmes, il en faudrait un pour
vector<int>::size_type, un autre pour vector<double>::size_type,
etc.) si size_t fera l'affaire dans tous les cas ?
J'utilise actuellement int dans les premiers exemples que je donne
à mes élèves, mais le compilateur peut donner des avertissements,
justifiés, car il y a alors mélange signé/non signé dans les
comparaisons avec size() et il est facile d'imaginer que int n'est
pas suffisant pour toutes les tailles possibles des vecteurs (en
particulier, si int a 16 bits). J'aimerais donc faire mieux, mais
sans avoir à expliquer les types imbriqués, les typedef, etc.,
avant d'avoir expliqué l'utilisation simple des vecteurs ! Dois-
je revenir aux vecteurs de base à la C ? J'aimerais mieux pouvoir
simplement utiliser size_t !
L'emploi de valeurs non signées comme indice n'est pas sans
problème non plus, car il est assez fréquent qu'un indice serve
dans un calcul mettant en scène des valeurs signées. Là encore,
le compilateur peut donner des avertissements... Inversement on
peut vouloir calculer un indice à partir de valeurs signées,
mais qui aimera écrire
int indice= ...
...
v[static_cast<vector(indice)]
au lieu de v[indice] !
N.B. BS utilise normalement int dans TC++PL... Je crois que je
vais lui écrire pour avoir son avis...
--
Michel Michaud [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
|
|
| Back to top |
|
 |
Gabriel Dos Reis
Guest
|
| Posted: Tue Jan 27, 2004 8:09 am Post subject: Re: size_t vs vector::size_type |
|
|
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
| Quote: | Il me semble que James a déjà démontré par des articles de la norme,
que vector<>::size_type ne peut pas être différent de size_t. Je me
trompe ?
|
Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
unsigned int, même si size_t est un unsigned long.
| Quote: | Est-il alors « correct » d'écrire :
vector<TypeQuelconque> v;
...
for (size_t i= 0; i != v.size(); ++i)
...
Je trouve difficile d'introduire vector::size_type rapidement.
Surtout lorsque les vecteurs contiennent des types personnels :
for (vector<TypeQuelconque>::size_type i= 0; i != v.size(); ++i)
C'est terriblement lourd, il me semble. Au point où il apparaît
qu'un typedef (pour vector<TypeQuelconque>::size_type) serait très
utile. Mais est-ce raisonnable de faire un typedef pour chaque type
|
Yep.
typedef vector<T>::size_type index_type;
| Quote: | de vector (dans bien des programmes, il en faudrait un pour
vector<int>::size_type, un autre pour vector<double>::size_type,
etc.) si size_t fera l'affaire dans tous les cas ?
|
C'est possible.
vector<>::size_type est une des abstractions excessives, malheureuses
de la bibliothèque standard.
[...]
| Quote: | L'emploi de valeurs non signées comme indice n'est pas sans
problème non plus, car il est assez fréquent qu'un indice serve
dans un calcul mettant en scène des valeurs signées. Là encore,
|
Yep, l'emploi des unsigned comme indices dans la bibliothèque standard
est quelque chose de regretable.
[...]
| Quote: | N.B. BS utilise normalement int dans TC++PL... Je crois que je
vais lui écrire pour avoir son avis...
|
Yep. Je crois que quelque part dans ce bouquin, il dit aussi ce qu'il
pense de l'emploi des unsigned ;-)
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Tue Jan 27, 2004 5:09 pm Post subject: Re: size_t vs vector::size_type |
|
|
Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> wrote
| Quote: | "Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
| Il me semble que James a déjà démontré par des articles de la norme,
| que vector<>::size_type ne peut pas être différent de size_t. Je me
| trompe ?
Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
unsigned int, même si size_t est un unsigned long.
|
Moi non plus. En fait, il y a deux questions : dans le cas général, il
me semble clair -- rien n'empêche d'écrire un allocateur avec un
size_type char, si cela t'enchante. En revanche, la norme exige bien que
le size_type de l'allocateur standard soit size_t. Reste la question si
le size_type de std::vector doit être identique au size_type de son
allocateur. Logiquement, je m'attendrais que si, mais je ne suis pas sûr
que la norme l'exige.
| Quote: | | Est-il alors « correct » d'écrire :
| vector<TypeQuelconque> v;
| ...
| for (size_t i= 0; i != v.size(); ++i)
| ...
| Je trouve difficile d'introduire vector::size_type rapidement.
|
Avec vi et compatibles :
:ab st std::vector<>::size_type
Par la suite, il faut retourner en arriére pour insérer le type
utilisateur. Mais ça aussi, on peut l'automatiser en partie.
Mais évidemment, ça n'est qu'une partie du problème. Le code est plus
facile à lire si les lignes ne sont pas excessivement longues non plus.
Et que les coupures de lignes ne viennent pas au milieu des expressions.
[...]
| Quote: | vector<>::size_type est une des abstractions excessives, malheureuses
de la bibliothèque standard.
|
Est-ce qu'on ne pourrait pas dire cela des allocateurs en général ?
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Jan 27, 2004 5:26 pm Post subject: Re: size_t vs vector::size_type |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
| Quote: | Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> wrote in message
news:<m3k73dbyoc.fsf (AT) merlin (DOT) cs.tamu.edu>...
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
| Il me semble que James a déjà démontré par des articles de la norme,
| que vector<>::size_type ne peut pas être différent de size_t. Je me
| trompe ?
Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
unsigned int, même si size_t est un unsigned long.
Moi non plus. En fait, il y a deux questions : dans le cas général, il
me semble clair -- rien n'empêche d'écrire un allocateur avec un
size_type char, si cela t'enchante. En revanche, la norme exige bien que
le size_type de l'allocateur standard soit size_t. Reste la question si
le size_type de std::vector doit être identique au size_type de son
allocateur. Logiquement, je m'attendrais que si, mais je ne suis pas sûr
que la norme l'exige.
|
La norme ne l'exige pas. Tout ce qu'elle dit c'est que c'est un
unsigned qui peut représenter les valeurs positives de
vector<>::difference_type -- qui lui même mesure la distance algébrique
entre deux itérateurs sur un vecteur, et un vector<T*>::iterator n'est
pas obligé à être un T*. Si on veut ête minimaliste, on peut dire que
c'est un type entier qui peut représenter
vector<>::allocator_type::max_size() / sizeof (T).
Dans la pratique, je ne sais pas s'il y a beaucoup d'implémentations
qui se compliquent la vie avec ce minimalisme.
-- Gaby
|
|
| Back to top |
|
|
Michel Michaud
Guest
|
| Posted: Tue Jan 27, 2004 6:03 pm Post subject: Re: size_t vs vector::size_type |
|
|
Dans news:m3k73dbyoc.fsf (AT) merlin (DOT) cs.tamu.edu, Gabriel Dos
Reis <gdr (AT) cs (DOT) tamu.edu> a écrit :
| Quote: | "Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
Il me semble que James a déjà démontré par des articles de la
norme, que vector<>::size_type ne peut pas être différent de
size_t. Je me trompe ?
Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
unsigned int, même si size_t est un unsigned long.
|
Est-ce que l'inverse est possible ? La vraie question est de
savoir si je peux utiliser size_t pour les indices des vecteurs.
Comme je le demandais juste après :
| Quote: | Est-il alors « correct » d'écrire :
vector<TypeQuelconque> v;
...
for (size_t i= 0; i != v.size(); ++i)
...
Je trouve difficile d'introduire vector::size_type rapidement.
|
Alors qu'il serait facile dire que size_t est le type des indices
des vecteurs...
| Quote: | Surtout lorsque les vecteurs contiennent des types personnels :
for (vector<TypeQuelconque>::size_type i= 0; i != v.size(); ++i)
C'est terriblement lourd, il me semble. Au point où il apparaît
qu'un typedef (pour vector<TypeQuelconque>::size_type) serait très
utile. Mais est-ce raisonnable de faire un typedef pour chaque type
Yep.
typedef vector<T>::size_type index_type;
|
template typedef ? :-)
| Quote: | N.B. BS utilise normalement int dans TC++PL... Je crois que je
vais lui écrire pour avoir son avis...
Yep. Je crois que quelque part dans ce bouquin, il dit aussi ce
qu'il pense de l'emploi des unsigned 
|
On peut bien dire ce qu'on veut, mais le C++ est le C++ et quand
on l'enseigne on ne peut pas passer à côté des choses qu'on
n'aime pas. Qu'enseignez-vous à vos élèves à College Station ?
À mettre int et à ne pas tenir compte des « warning » ? On peut
choisir notre compilateur (ou ses options) pour ne pas avoir les
avertissements, mais alors on ne fait pas du C++ très propre...
--
Michel Michaud [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
|
|
| Back to top |
|
|
Michel Michaud
Guest
|
| Posted: Tue Jan 27, 2004 6:06 pm Post subject: Re: size_t vs vector::size_type |
|
|
Dans news:d6652001.0401270909.6eed46f1 (AT) posting (DOT) google.com,
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> a écrit :
| Quote: | Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> wrote in message
news:<m3k73dbyoc.fsf (AT) merlin (DOT) cs.tamu.edu>...
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
Je trouve difficile d'introduire vector::size_type rapidement.
Avec vi et compatibles :
:ab st std::vector<>::size_type
Par la suite, il faut retourner en arriére pour insérer le type
utilisateur. Mais ça aussi, on peut l'automatiser en partie.
|
La difficulté n'est pas de le taper, mais de le justifier ou de
l'expliquer aux débutants...
| Quote: | Mais évidemment, ça n'est qu'une partie du problème. Le code est
plus facile à lire si les lignes ne sont pas excessivement longues
non plus. Et que les coupures de lignes ne viennent pas au milieu
des expressions.
|
Dans une boucle for avec size_type, la déclaration de la variable
de contrôle prend en effet beaucoup de place et presque toute la
place !
Dans la pratique James, tu écris quoi ?
--
Michel Michaud [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue Jan 27, 2004 8:43 pm Post subject: Re: size_t vs vector::size_type |
|
|
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
| Quote: | Dans news:m3k73dbyoc.fsf (AT) merlin (DOT) cs.tamu.edu, Gabriel Dos
Reis <gdr (AT) cs (DOT) tamu.edu> a écrit :
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
Il me semble que James a déjà démontré par des articles de la
norme, que vector<>::size_type ne peut pas être différent de
size_t. Je me trompe ?
Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
unsigned int, même si size_t est un unsigned long.
Est-ce que l'inverse est possible ?
|
Oui. Mais cela ne te dit rien sur ce qu'il est. C'est pour ça qu'ils
l'ont appelé une abstraction.
| Quote: | La vraie question est de
savoir si je peux utiliser size_t pour les indices des vecteurs.
Comme je le demandais juste après :
|
Je crois que j'ai répondu que « int » est l'indice naturel, même si la
norme, dans ses excès d'abstraction, utilise xxx::size_type.
Est-ce que tu utilises
v[vector<T>::size_type(2)]
ou simplement
v[2];
[...]
| Quote: | N.B. BS utilise normalement int dans TC++PL... Je crois que je
vais lui écrire pour avoir son avis...
Yep. Je crois que quelque part dans ce bouquin, il dit aussi ce
qu'il pense de l'emploi des unsigned ;-)
On peut bien dire ce qu'on veut, mais le C++ est le C++ et quand
|
Personne ne dit le contraire.
| Quote: | on l'enseigne on ne peut pas passer à côté des choses qu'on
n'aime pas. Qu'enseignez-vous à vos élèves à College Station ?
|
Nous leur enseignons la programmation (et non C++) 
Nous utilisons C++, mais nous allons rapidement à l'essentiel des
concepts. Par exemple, le prochain cours (4ième) sera sur les
exceptions. Nous en avons besoin pour les introduire assez tôt à la
gestion des erreurs.
En particulier, pour les cours nous utilisons des entêtes qui
encapsulent certains détails inintéressants ; les accès aux tableaux
sont vérifiés par défaut (le contraire de ce que tu as dans la
bibliothèque standard).
| Quote: | À mettre int et à ne pas tenir compte des « warning » ? On peut
choisir notre compilateur (ou ses options) pour ne pas avoir les
avertissements, mais alors on ne fait pas du C++ très propre...
|
Je le transmettrai à qui de droit :-)
-- Gaby
|
|
| Back to top |
|
|
Michel Michaud
Guest
|
| Posted: Tue Jan 27, 2004 10:21 pm Post subject: Re: size_t vs vector::size_type |
|
|
Dans news:m3isixcebt.fsf (AT) uniton (DOT) integrable-solutions.net, Gabriel Dos
Reis <gdr (AT) integrable-solutions (DOT) net> a écrit :
| Quote: | "Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
Dans news:m3k73dbyoc.fsf (AT) merlin (DOT) cs.tamu.edu, Gabriel Dos
Reis <gdr (AT) cs (DOT) tamu.edu> a écrit :
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
Il me semble que James a déjà démontré par des articles de la
norme, que vector<>::size_type ne peut pas être différent de
size_t. Je me trompe ?
Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
unsigned int, même si size_t est un unsigned long.
Est-ce que l'inverse est possible ?
Oui. Mais cela ne te dit rien sur ce qu'il est. C'est pour ça qu'ils
l'ont appelé une abstraction.
|
Mais ça me dit que size_t n'est pas sûr. C'est beaucoup !
| Quote: | La vraie question est de
savoir si je peux utiliser size_t pour les indices des vecteurs.
Comme je le demandais juste après :
Je crois que j'ai répondu que « int » est l'indice naturel, même si
la norme, dans ses excès d'abstraction, utilise xxx::size_type.
|
Un indice naturel qui peut ne pas fonctionner et/ou donner des
avertissements des « bons » compilateurs !
:-(
| Quote: |
Est-ce que tu utilises
v[vector<T>::size_type(2)]
ou simplement
v[2];
|
Ni l'un ni l'autre ! À part [0], je ne me rappelle pas quand
j'ai utilisé une constante comme indice, sinon j'opterais
probablement pour
v[static_cast<std::vector(2)]
Tant qu'à y être ! :-)
Plus sérieusement, si v.size() > 100000, je sais que je peux
faire v[100000]= 0;, mais rien ne me dit que je peux faire
int i=100000; v[i]= 0;. Par contre, je peux faire i=35000;
v[i]= 0;, n'est-ce pas ? Brrrr....
| Quote: | n'aime pas. Qu'enseignez-vous à vos élèves à College Station ?
Nous leur enseignons la programmation (et non C++)
|
Moi aussi. Et si jamais, on me démontre qu'il y a trop de
problème pour ce que soit un bon outil, je vais penser à en
changer ! Ce n'est pas mon intention pour le moment, les
avantages me paraissent toujours supérieurs...
| Quote: | Nous utilisons C++, mais nous allons rapidement à l'essentiel des
concepts. Par exemple, le prochain cours (4ième) sera sur les
exceptions. Nous en avons besoin pour les introduire assez tôt à la
gestion des erreurs.
En particulier, pour les cours nous utilisons des entêtes qui
|
(en-tête Gabriel, en-tête... :-)
| Quote: | encapsulent certains détails inintéressants ; les accès aux tableaux
sont vérifiés par défaut (le contraire de ce que tu as dans la
bibliothèque standard).
|
Moi aussi v[i] est vérifié. Mais vous utilisez std::vector ou non ?
Tu ne m'as pas dit explicitement de quel type tu déclares les
indices (je suppose que c'est int...).
| Quote: | À mettre int et à ne pas tenir compte des « warning » ? On peut
choisir notre compilateur (ou ses options) pour ne pas avoir les
avertissements, mais alors on ne fait pas du C++ très propre...
Je le transmettrai à qui de droit
|
J'ai toujours dit que, dans le doute, je préfère choisir de faire
comme BS, car ça me donne un justification assez sérieuse. Ceci dit,
c'est Koenig qui fait un peu référence pour les livres d'introduction
et il utilise size_type... En plus, depuis que VC peut compiler du
code conforme sans avertissement en mettant le niveau le plus élevé
d'avertissements, j'aimerais pouvoir mettre ce niveau, qui détecte
plusieurs petites erreurs utiles... Malheureusement, ce niveau n'aime
pas tellement les conversions signed/unsigned implicites...
Je crois qu'on est d'accord cependant : l'erreur est d'avoir introduit
les unsigned dans les vector comme indice. Ça donne vraiment peu
d'avantages quand on compare aux autres difficultés...
--
Michel Michaud [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
|
|
| Back to top |
|
|
Loïc Joly
Guest
|
| Posted: Wed Jan 28, 2004 12:34 am Post subject: Re: size_t vs vector::size_type |
|
|
Gabriel Dos Reis wrote:
| Quote: | | La vraie question est de
| savoir si je peux utiliser size_t pour les indices des vecteurs.
| Comme je le demandais juste après :
Je crois que j'ai répondu que « int » est l'indice naturel, même si la
norme, dans ses excès d'abstraction, utilise xxx::size_type.
Est-ce que tu utilises
v[vector<T>::size_type(2)]
ou simplement
v[2];
|
Ca me fait poser une question : Dans la norme, je lis que
vector<T>::size_type est un unsigned integral type. Est-ce que ça veut
dire qu'il fait forcément partie de l'ensemble {unsigned char, unsigned
short, unsigned int, unsigned long int}, ou est-ce qu'il pourraît être
défini comme un type utilisateur ou un type extention du compilateur ?
--
Loïc
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Wed Jan 28, 2004 12:45 am Post subject: Re: size_t vs vector::size_type |
|
|
Loïc Joly <loic.actarus.joly (AT) wanadoo (DOT) fr> writes:
| Quote: | Gabriel Dos Reis wrote:
| La vraie question est de
| savoir si je peux utiliser size_t pour les indices des vecteurs.
| Comme je le demandais juste après :
Je crois que j'ai répondu que « int » est l'indice naturel, même si
la
norme, dans ses excès d'abstraction, utilise xxx::size_type.
Est-ce que tu utilises
v[vector<T>::size_type(2)]
ou simplement
v[2];
Ca me fait poser une question : Dans la norme, je lis que
vector<T>::size_type est un unsigned integral type. Est-ce que ça veut
dire qu'il fait forcément partie de l'ensemble {unsigned char,
unsigned short, unsigned int, unsigned long int}, ou est-ce qu'il
pourraît être défini comme un type utilisateur ou un type extention du
compilateur ?
|
Avec la définition de C90 (qui est celle incluse dans C++), cela fait
forcément partie de l'ensemble que tu as énuméré. Si C++ évoluait pour
adopter la définition de C99, alors cela pourrait être un type
extension du compilateur.
-- Gaby
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Wed Jan 28, 2004 12:53 am Post subject: Re: size_t vs vector::size_type |
|
|
"Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
[...]
| Quote: | Plus sérieusement, si v.size() > 100000, je sais que je peux
faire v[100000]= 0;, mais rien ne me dit que je peux faire
int i=100000; v[i]= 0;. Par contre, je peux faire i=35000;
v[i]= 0;, n'est-ce pas ? Brrrr....
|
Ou tu peux aussi faire v.at(i) :-)
[...]
| Quote: | encapsulent certains détails inintéressants ; les accès aux tableaux
sont vérifiés par défaut (le contraire de ce que tu as dans la
bibliothèque standard).
Moi aussi v[i] est vérifié. Mais vous utilisez std::vector ou non ?
|
Avant qu'il deviennent « mûrs », ils utilises « vector » -- sans
qualification.
| Quote: | Tu ne m'as pas dit explicitement de quel type tu déclares les
indices (je suppose que c'est int...).
|
for (int i = 0; i < N; ++i)
v[i] = xxxx;
| Quote: | À mettre int et à ne pas tenir compte des « warning » ? On peut
choisir notre compilateur (ou ses options) pour ne pas avoir les
avertissements, mais alors on ne fait pas du C++ très propre...
Je le transmettrai à qui de droit :-)
J'ai toujours dit que, dans le doute, je préfère choisir de faire
comme BS, car ça me donne un justification assez sérieuse. Ceci dit,
|
Il est cohérent avec ce qu'il écrit dans son bouquin :-)
(et je crois que la formulation de sa pensée dans le bouquin est
nettement supérieure à ce que je pourrais dire sur son compte ici ;-p)
| Quote: | c'est Koenig qui fait un peu référence pour les livres d'introduction
et il utilise size_type... En plus, depuis que VC peut compiler du
code conforme sans avertissement en mettant le niveau le plus élevé
d'avertissements, j'aimerais pouvoir mettre ce niveau, qui détecte
plusieurs petites erreurs utiles... Malheureusement, ce niveau n'aime
pas tellement les conversions signed/unsigned implicites...
|
Ben dans ce cas, utilises std::size_t.
| Quote: | Je crois qu'on est d'accord cependant : l'erreur est d'avoir introduit
les unsigned dans les vector comme indice. Ça donne vraiment peu
d'avantages quand on compare aux autres difficultés...
|
Yep.
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Wed Jan 28, 2004 7:52 am Post subject: Re: size_t vs vector::size_type |
|
|
"Michel Michaud" <mm (AT) gdzid (DOT) com> wrote
[...]
| Quote: | Dans une boucle for avec size_type, la déclaration de la variable de
contrôle prend en effet beaucoup de place et presque toute la place !
Dans la pratique James, tu écris quoi ?
|
size_t.
Dans la pratique, je vois mal une implémentation qui utilise d'autre
chose, même si c'est permis en théorie. Je suis même rassurer par la
poste de Gabriel, où il indique qu'il faut que le type soit non-signé.
(Et on sait qu'avec l'allocateur standard, les indices d'un vector ne
peut pas prendre des valeurs qui dépasse les limites d'un size_t.)
Mais en général, quand je me sers de std::vector, je me sers plutôt de
std::vector<>::iterator ou std::vector<>::const_iterator:-).
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Wed Jan 28, 2004 7:59 am Post subject: Re: size_t vs vector::size_type |
|
|
Gabriel Dos Reis <gdr (AT) integrable-solutions (DOT) net> wrote
| Quote: | kanze (AT) gabi-soft (DOT) fr writes:
| Gabriel Dos Reis <gdr (AT) cs (DOT) tamu.edu> wrote in message
| news:<m3k73dbyoc.fsf (AT) merlin (DOT) cs.tamu.edu>...
| > "Michel Michaud" <mm (AT) gdzid (DOT) com> writes:
| > | Il me semble que James a déjà démontré par des articles de la
| > | norme, que vector<>::size_type ne peut pas être différent de
| > | size_t. Je me trompe ?
| > Je ne me souviens pas. Je ne vois pas ce qui l'empêche d'être un
| > unsigned int, même si size_t est un unsigned long.
| Moi non plus. En fait, il y a deux questions : dans le cas général,
| il me semble clair -- rien n'empêche d'écrire un allocateur avec un
| size_type char, si cela t'enchante. En revanche, la norme exige bien
| que le size_type de l'allocateur standard soit size_t. Reste la
| question si le size_type de std::vector doit être identique au
| size_type de son allocateur. Logiquement, je m'attendrais que si,
| mais je ne suis pas sûr que la norme l'exige.
La norme ne l'exige pas. Tout ce qu'elle dit c'est que c'est un
unsigned
|
Type entier de la norme, j'espère. L'implémentation n'a pas le droit
d'inventer son propre type pour le faire (qui ne se convertira même pas
implicitement en size_t). Ou ?
| Quote: | qui peut représenter les valeurs positives de
vector<>::difference_type -- qui lui même mesure la distance algébrique
entre deux itérateurs sur un vecteur, et un vector<T*>::iterator n'est
pas obligé à être un T*. Si on veut ête minimaliste, on peut dire que
c'est un type entier qui peut représenter
vector<>::allocator_type::max_size() / sizeof (T).
|
Donc, pas de risque de débordement si je me sers d'un size_t (et
uniquement de l'allocator standard).
| Quote: | Dans la pratique, je ne sais pas s'il y a beaucoup d'implémentations
qui se compliquent la vie avec ce minimalisme.
|
Je crois que c'était entendu qu'on parlait de ce qui était permis, et
non seulement de ce qui se fait ou de qui risque de se faire.
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
|
|
| Back to top |
|
|
Samuel Krempp
Guest
|
| Posted: Wed Jan 28, 2004 3:34 pm Post subject: Re: size_t vs vector::size_type |
|
|
le Wednesday 28 January 2004 01:53, [email]gdr (AT) cs (DOT) tamu.edu[/email] écrivit :
| Quote: | Avant qu'il deviennent « mûrs », ils utilises « vector » -- sans
qualification.
|
qui est donc un type fourni par l'inclusion d'un en-tête maison si je
comprends bien.
ce type encapsule std::vector et fournit toute une interface similaire à
std::vector (à qques détails prêt dont le type de size() et des indices)
genre
template <typename T>
class vector {
std::vector<T> v_;
public :
int size() const;
T& operator[] (int i); range-check puis v_[i]
// resize(..) assign(..) et tout le reste ..
....
};
c'est ça ? ou bien le maximum de fonction est repris directment en héritant
de std::vector plutot qu'aggrégation ?
| Quote: | | Tu ne m'as pas dit explicitement de quel type tu déclares les
| indices (je suppose que c'est int...).
for (int i = 0; i < N; ++i)
v[i] = xxxx;
|
C'est ce que j'avais décidé de prendre l'habitude de faire au début, je
considèrais que je n'avais pas particulierement besoin d'un bit de plus
pour les tailles maximales et que je préferais éviter tant que possible de
me frotter à des problèmes de signé/non-signés, mais le fait que tout ce
qui existe utilise des non-signés m'a vite fait laisser de coté cette
philosophie, et j'ai malgré moi pris l'habitude de déclarer mes indices en
size_t, et de m'embêter à expliciter et vérifier les conversion
signé/non-signé.. (ou de les oublier carrément)
Est-ce que tu as une bonne solution pour permettre de garder le choix des
signés tout en pouvant s'adapter ensuite à des containers qui utilisent des
indices non-signé ?
#pragma bidule désactive le warning des comparaison signé/non-signé
for(int i=0; i
m'embête un peu, puisque le jour éventuel où le cas se présente d'un
v.size() pas représentable sur un int, la boucle ne finira pas et on ne
saura pas pquoi. (ou alors si v.size() est juste unsigned int, la boucle
finira comme il faut mais en passant par des i négatifs qui pourraient
poser problème dans le corps de la boucle)
J'ai envisagé d'adopter une habitude dans le genre de :
template
int sz2int(SizeType sz) {
int ret = static_cast<int> (sz);
assert(sz == ret); // promote & compare
assert(ret >= 0);
return ret;
}
....
for(int i=0; i
mais je n'étais pas très sûr de ce que je devrais mettre dans sz2int.
Là j'ai réfléchi un peu avant de faire celui-ci, et il me semble que c'est
transparent si SizeType est en fait plus petit que int, que ça fait ce
qu'il faut quand SizeType est unsigned int ou unsigned long, et que dans
l'hypothèse où SizeType serait un type (ajouté) encore plus grand, ça
pourrait encore marcher pour peu que l'operator== fasse ce qu'il faut..
est ce que cette façon de faire est valable dans les cas où on décide de se
limiter au traitement de containers dont les indices tiennent dans un int
ou ya des trucs auxquels j'ai pas pensé ?
| Quote: | Il est cohérent avec ce qu'il écrit dans son bouquin
|
ça nous dit pas comment il fait concretement pour adapter correctment
l'utilisation de la stdlib à son choix d'utiliser des indices signés, je
crois que les exmples du bouquin ne vont pas au delà de boucles que je
préfererais éviter, genre p94 :
void fp(char v[] , unsigned int size) {
for (int i=0; i
--
Sam
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Wed Jan 28, 2004 11:42 pm Post subject: Re: size_t vs vector::size_type |
|
|
Samuel Krempp <krempp (AT) crans (DOT) truc.en.trop.ens-cachan.fr> writes:
| Quote: | le Wednesday 28 January 2004 01:53, [email]gdr (AT) cs (DOT) tamu.edu[/email] écrivit :
Avant qu'il deviennent « mûrs », ils utilises « vector » -- sans
qualification.
qui est donc un type fourni par l'inclusion d'un en-tête maison si je
comprends bien.
|
Yep.
| Quote: | ce type encapsule std::vector et fournit toute une interface similaire à
std::vector (à qques détails prêt dont le type de size() et des indices)
genre
template <typename T
class vector {
std::vector
public :
int size() const;
T& operator[] (int i); range-check puis v_[i]
// resize(..) assign(..) et tout le reste ..
...
};
c'est ça ? ou bien le maximum de fonction est repris directment en héritant
de std::vector plutot qu'aggrégation ?
|
Yep.
template<class T, class A = std::allocator
struct vector : std::vector<T, A> {
// forwarding constructors
// define operator[] to do the "right thing"
};
| Quote: | | Tu ne m'as pas dit explicitement de quel type tu déclares les
| indices (je suppose que c'est int...).
for (int i = 0; i < N; ++i)
v[i] = xxxx;
C'est ce que j'avais décidé de prendre l'habitude de faire au début, je
considèrais que je n'avais pas particulierement besoin d'un bit de plus
pour les tailles maximales et que je préferais éviter tant que possible de
me frotter à des problèmes de signé/non-signés, mais le fait que tout ce
qui existe utilise des non-signés m'a vite fait laisser de coté cette
philosophie, et j'ai malgré moi pris l'habitude de déclarer mes indices en
size_t, et de m'embêter à expliciter et vérifier les conversion
signé/non-signé.. (ou de les oublier carrément)
|
Oui, c'est une réel problème :-(
| Quote: | Est-ce que tu as une bonne solution pour permettre de garder le choix des
signés tout en pouvant s'adapter ensuite à des containers qui utilisent des
indices non-signé ?
#pragma bidule désactive le warning des comparaison signé/non-signé
for(int i=0; i
m'embête un peu, puisque le jour éventuel où le cas se présente d'un
v.size() pas représentable sur un int, la boucle ne finira pas et on ne
saura pas pquoi. (ou alors si v.size() est juste unsigned int, la boucle
finira comme il faut mais en passant par des i négatifs qui pourraient
poser problème dans le corps de la boucle)
|
Oui, tout ce qui commence par CPP est un non-starter.
| Quote: | J'ai envisagé d'adopter une habitude dans le genre de :
template
int sz2int(SizeType sz) {
int ret = static_cast
assert(sz == ret); // promote & compare
assert(ret >= 0);
return ret;
}
...
for(int i=0; i
mais je n'étais pas très sûr de ce que je devrais mettre dans sz2int.
|
Par défaut je lèverais un exception, à moins d'avoir des information
me disant qu'il vaut mieux utiliser assert() -- qui n'est pas toujours
sous contrôle.
| Quote: | Là j'ai réfléchi un peu avant de faire celui-ci, et il me semble que c'est
transparent si SizeType est en fait plus petit que int, que ça fait ce
qu'il faut quand SizeType est unsigned int ou unsigned long, et que dans
l'hypothèse où SizeType serait un type (ajouté) encore plus grand, ça
pourrait encore marcher pour peu que l'operator== fasse ce qu'il faut..
|
Yep.
| Quote: | est ce que cette façon de faire est valable dans les cas où on décide de se
limiter au traitement de containers dont les indices tiennent dans un int
ou ya des trucs auxquels j'ai pas pensé ?
|
je crois que oui.
| Quote: | Il est cohérent avec ce qu'il écrit dans son bouquin :-)
ça nous dit pas comment il fait concretement pour adapter correctment
l'utilisation de la stdlib à son choix d'utiliser des indices signés, je
crois que les exmples du bouquin ne vont pas au delà de boucles que je
préfererais éviter, genre p94 :
void fp(char v[] , unsigned int size) {
for (int i=0; i
|
C'est vrai. Si tu regardes bien, il utilise les iterator là où cela
devient non trivial. En fait, si tu adhères à la religion que tes
fonctions ne devraient pas faire plus d'une quizaine de lignes, il est
fréquent que la plupart des structures de contrôle s'expriment en
terme d'itérateurs.
-- Gaby
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
