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<TypeQuelconque>::size_type>(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 mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Ces discussions ont toujours un contexte précis. Si on oublie le context, on risque de pédaler dans le vide. En particulier, ces discussions supposent qu'il y a connaissance de l'exitence de la classe de base et que certains feraient des bêtises avec. Mais dans le contexte actuel, à part le prof, personne ne sait l'existance de la classe de base. Il n'y a donc aucun risque.
D'accord. sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait au départ que l'interface, qu'est ce qu'il faut regarder pour savoir quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur qui fait qque chose alors que le destructeur de la classe de base n'est pas virtuel ?
Je vois une perfidie possible dans l'implémentation de la classe de base, ce serait qu'elle utilise du RTTI dans une fction membre d'une façon malsaine et ne supporte pas que celui-ci soit le nom d'une classe dérivée. Ca donne bien un moyen de pièger une classe contre tout héritier potentiel (et là, même sans utilisation polymorphique) non ? est-ce qu'il y a d'autres pièges moins hypothetiques ?
si tu me donnes un référence pour aller me rafraîchir les idées sur ce sujet je serais pleinement satisfait
| Ce que je ne sais pas dans le fond, c'est si on peut être sûr de ne | courir aucun risque en dérivant une classe qui n'offre aucune garantie à | ses héritiers éventuels.
Je ne comprends pas cette phrase. Si j'hérite d'une classe, j'hérite de toutes ces fonctions membres. Surtout n'oublie pas le contexte spécifique sous la main.
je voulais dire, en ne voyant que l'interface d'une classe, et qu'elle ne précise rien quand à son comportement quand elle est héritée, quels risques peuvent exister.. en fait je ne parlais pas précisément du cas de ce vector.
| Je n'en vois aucun, mais je n'ai jamais cherché à | connaître toutes les conséquences imaginables de dériver une classe..
Est-ce important dans le cas spécifique sous la main ?
ah non, je ne dis pas le contraire :) je profite juste de l'occasion pour m'éclaircir les idées sur ce sujet. Comme ça la prochaine fois que je voudrai dériver une classe non prévue pour, je saurai quoi vérifier au préalable.
Quelle est la dernière fois que tu as fais des bêtises avec std::_Vector_base et std::vector à cause de la dérivation ?
ça ne m'est jamais arrivé :) mais ces 2 classes ont été écrites pour collaborer, donc c'est qd même la moindre des choses
-- Sam
le Saturday 31 January 2004 06:22, gdr@cs.tamu.edu écrivit :
Ces discussions ont toujours un contexte précis. Si on oublie le
context, on risque de pédaler dans le vide. En particulier, ces
discussions supposent qu'il y a connaissance de l'exitence de la
classe de base et que certains feraient des bêtises avec. Mais dans le
contexte actuel, à part le prof, personne ne sait l'existance de la
classe de base. Il n'y a donc aucun risque.
D'accord.
sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait
au départ que l'interface, qu'est ce qu'il faut regarder pour savoir
quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur
qui fait qque chose alors que le destructeur de la classe de base n'est pas
virtuel ?
Je vois une perfidie possible dans l'implémentation de la classe de base, ce
serait qu'elle utilise du RTTI dans une fction membre d'une façon malsaine
et ne supporte pas que celui-ci soit le nom d'une classe dérivée. Ca donne
bien un moyen de pièger une classe contre tout héritier potentiel (et là,
même sans utilisation polymorphique) non ?
est-ce qu'il y a d'autres pièges moins hypothetiques ?
si tu me donnes un référence pour aller me rafraîchir les idées sur ce sujet
je serais pleinement satisfait
| Ce que je ne sais pas dans le fond, c'est si on peut être sûr de ne
| courir aucun risque en dérivant une classe qui n'offre aucune garantie à
| ses héritiers éventuels.
Je ne comprends pas cette phrase. Si j'hérite d'une classe, j'hérite
de toutes ces fonctions membres. Surtout n'oublie pas le contexte
spécifique sous la main.
je voulais dire, en ne voyant que l'interface d'une classe, et qu'elle ne
précise rien quand à son comportement quand elle est héritée, quels risques
peuvent exister.. en fait je ne parlais pas précisément du cas de ce
vector.
| Je n'en vois aucun, mais je n'ai jamais cherché à
| connaître toutes les conséquences imaginables de dériver une classe..
Est-ce important dans le cas spécifique sous la main ?
ah non, je ne dis pas le contraire :)
je profite juste de l'occasion pour m'éclaircir les idées sur ce sujet.
Comme ça la prochaine fois que je voudrai dériver une classe non prévue
pour, je saurai quoi vérifier au préalable.
Quelle est la dernière fois que tu as fais des bêtises avec
std::_Vector_base et std::vector à cause de la dérivation ?
ça ne m'est jamais arrivé :)
mais ces 2 classes ont été écrites pour collaborer, donc c'est qd même la
moindre des choses
Ces discussions ont toujours un contexte précis. Si on oublie le context, on risque de pédaler dans le vide. En particulier, ces discussions supposent qu'il y a connaissance de l'exitence de la classe de base et que certains feraient des bêtises avec. Mais dans le contexte actuel, à part le prof, personne ne sait l'existance de la classe de base. Il n'y a donc aucun risque.
D'accord. sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait au départ que l'interface, qu'est ce qu'il faut regarder pour savoir quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur qui fait qque chose alors que le destructeur de la classe de base n'est pas virtuel ?
Je vois une perfidie possible dans l'implémentation de la classe de base, ce serait qu'elle utilise du RTTI dans une fction membre d'une façon malsaine et ne supporte pas que celui-ci soit le nom d'une classe dérivée. Ca donne bien un moyen de pièger une classe contre tout héritier potentiel (et là, même sans utilisation polymorphique) non ? est-ce qu'il y a d'autres pièges moins hypothetiques ?
si tu me donnes un référence pour aller me rafraîchir les idées sur ce sujet je serais pleinement satisfait
| Ce que je ne sais pas dans le fond, c'est si on peut être sûr de ne | courir aucun risque en dérivant une classe qui n'offre aucune garantie à | ses héritiers éventuels.
Je ne comprends pas cette phrase. Si j'hérite d'une classe, j'hérite de toutes ces fonctions membres. Surtout n'oublie pas le contexte spécifique sous la main.
je voulais dire, en ne voyant que l'interface d'une classe, et qu'elle ne précise rien quand à son comportement quand elle est héritée, quels risques peuvent exister.. en fait je ne parlais pas précisément du cas de ce vector.
| Je n'en vois aucun, mais je n'ai jamais cherché à | connaître toutes les conséquences imaginables de dériver une classe..
Est-ce important dans le cas spécifique sous la main ?
ah non, je ne dis pas le contraire :) je profite juste de l'occasion pour m'éclaircir les idées sur ce sujet. Comme ça la prochaine fois que je voudrai dériver une classe non prévue pour, je saurai quoi vérifier au préalable.
Quelle est la dernière fois que tu as fais des bêtises avec std::_Vector_base et std::vector à cause de la dérivation ?
ça ne m'est jamais arrivé :) mais ces 2 classes ont été écrites pour collaborer, donc c'est qd même la moindre des choses
-- Sam
Alain Naigeon
"Samuel Krempp" a écrit dans le message news: 401ba768$0$19002$
le Saturday 31 January 2004 06:22, écrivit :
Ces discussions ont toujours un contexte précis. Si on oublie le context, on risque de pédaler dans le vide. En particulier, ces discussions supposent qu'il y a connaissance de l'exitence de la classe de base et que certains feraient des bêtises avec. Mais dans le contexte actuel, à part le prof, personne ne sait l'existance de la classe de base. Il n'y a donc aucun risque.
D'accord. sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait
au départ que l'interface, qu'est ce qu'il faut regarder pour savoir quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur qui fait qque chose alors que le destructeur de la classe de base n'est pas
virtuel ?
Si quelqu'un en amont a fait une grosse bêtise, ça ne sert plus à rien d'éviter, toi, d'en faire des petites.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Samuel Krempp" <krempp@crans.truc.en.trop.ens-cachan.fr> a écrit dans le
message news: 401ba768$0$19002$636a55ce@news.free.fr...
le Saturday 31 January 2004 06:22, gdr@cs.tamu.edu écrivit :
Ces discussions ont toujours un contexte précis. Si on oublie le
context, on risque de pédaler dans le vide. En particulier, ces
discussions supposent qu'il y a connaissance de l'exitence de la
classe de base et que certains feraient des bêtises avec. Mais dans le
contexte actuel, à part le prof, personne ne sait l'existance de la
classe de base. Il n'y a donc aucun risque.
D'accord.
sinon, dans le cas où l'on envisage de dériver une classe dont on ne
connait
au départ que l'interface, qu'est ce qu'il faut regarder pour savoir
quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur
qui fait qque chose alors que le destructeur de la classe de base n'est
pas
virtuel ?
Si quelqu'un en amont a fait une grosse bêtise,
ça ne sert plus à rien d'éviter, toi, d'en faire des
petites.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Samuel Krempp" a écrit dans le message news: 401ba768$0$19002$
le Saturday 31 January 2004 06:22, écrivit :
Ces discussions ont toujours un contexte précis. Si on oublie le context, on risque de pédaler dans le vide. En particulier, ces discussions supposent qu'il y a connaissance de l'exitence de la classe de base et que certains feraient des bêtises avec. Mais dans le contexte actuel, à part le prof, personne ne sait l'existance de la classe de base. Il n'y a donc aucun risque.
D'accord. sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait
au départ que l'interface, qu'est ce qu'il faut regarder pour savoir quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur qui fait qque chose alors que le destructeur de la classe de base n'est pas
virtuel ?
Si quelqu'un en amont a fait une grosse bêtise, ça ne sert plus à rien d'éviter, toi, d'en faire des petites.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Gabriel Dos Reis
Samuel Krempp writes:
| le Saturday 31 January 2004 06:22, écrivit : | | > Ces discussions ont toujours un contexte précis. Si on oublie le | > context, on risque de pédaler dans le vide. En particulier, ces | > discussions supposent qu'il y a connaissance de l'exitence de la | > classe de base et que certains feraient des bêtises avec. Mais dans le | > contexte actuel, à part le prof, personne ne sait l'existance de la | > classe de base. Il n'y a donc aucun risque. | | D'accord. | sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait | au départ que l'interface, qu'est ce qu'il faut regarder pour savoir | quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur | qui fait qque chose alors que le destructeur de la classe de base n'est pas | virtuel ?
Ne pas essayer de détruire l'objet avec un pointer sur la classe de base.
| Je vois une perfidie possible dans l'implémentation de la classe de base, ce | serait qu'elle utilise du RTTI dans une fction membre d'une façon malsaine
| et ne supporte pas que celui-ci soit le nom d'une classe dérivée. Ca donne | bien un moyen de pièger une classe contre tout héritier potentiel (et là, | même sans utilisation polymorphique) non ?
C++ ne te protège pas de Machiavel, nous sommes d'accord.
| est-ce qu'il y a d'autres pièges moins hypothetiques ? | | si tu me donnes un référence pour aller me rafraîchir les idées sur ce sujet | je serais pleinement satisfait
Des références sur ?
[...]
| Comme ça la prochaine fois que je voudrai dériver une classe non prévue | pour, je saurai quoi vérifier au préalable.
Si la documentation dit « DO NOT DERIVE FROM THIS CLASS!!!! », alors ne le fais pas. Sinon, tu le fais avec une utilisation raisonable, tu ne devrais pas avoir de problème. Désolé, je n'ai pas de formule « close » pour déterminer quand quelque chose est raisonnable :-/
| > Quelle est la dernière fois que tu as fais des bêtises avec | > std::_Vector_base et std::vector à cause de la dérivation ? | | ça ne m'est jamais arrivé :) | mais ces 2 classes ont été écrites pour collaborer, donc c'est qd même la | moindre des choses
Dans ce cas, on ne devrait pas avoir l'héritage multiple ;-)
-- Gaby
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
| le Saturday 31 January 2004 06:22, gdr@cs.tamu.edu écrivit :
|
| > Ces discussions ont toujours un contexte précis. Si on oublie le
| > context, on risque de pédaler dans le vide. En particulier, ces
| > discussions supposent qu'il y a connaissance de l'exitence de la
| > classe de base et que certains feraient des bêtises avec. Mais dans le
| > contexte actuel, à part le prof, personne ne sait l'existance de la
| > classe de base. Il n'y a donc aucun risque.
|
| D'accord.
| sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait
| au départ que l'interface, qu'est ce qu'il faut regarder pour savoir
| quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur
| qui fait qque chose alors que le destructeur de la classe de base n'est pas
| virtuel ?
Ne pas essayer de détruire l'objet avec un pointer sur la classe de
base.
| Je vois une perfidie possible dans l'implémentation de la classe de base, ce
| serait qu'elle utilise du RTTI dans une fction membre d'une façon malsaine
| et ne supporte pas que celui-ci soit le nom d'une classe dérivée. Ca donne
| bien un moyen de pièger une classe contre tout héritier potentiel (et là,
| même sans utilisation polymorphique) non ?
C++ ne te protège pas de Machiavel, nous sommes d'accord.
| est-ce qu'il y a d'autres pièges moins hypothetiques ?
|
| si tu me donnes un référence pour aller me rafraîchir les idées sur ce sujet
| je serais pleinement satisfait
Des références sur ?
[...]
| Comme ça la prochaine fois que je voudrai dériver une classe non prévue
| pour, je saurai quoi vérifier au préalable.
Si la documentation dit « DO NOT DERIVE FROM THIS CLASS!!!! », alors
ne le fais pas. Sinon, tu le fais avec une utilisation raisonable, tu
ne devrais pas avoir de problème. Désolé, je n'ai pas de formule
« close » pour déterminer quand quelque chose est raisonnable :-/
| > Quelle est la dernière fois que tu as fais des bêtises avec
| > std::_Vector_base et std::vector à cause de la dérivation ?
|
| ça ne m'est jamais arrivé :)
| mais ces 2 classes ont été écrites pour collaborer, donc c'est qd même la
| moindre des choses
Dans ce cas, on ne devrait pas avoir l'héritage multiple ;-)
| le Saturday 31 January 2004 06:22, écrivit : | | > Ces discussions ont toujours un contexte précis. Si on oublie le | > context, on risque de pédaler dans le vide. En particulier, ces | > discussions supposent qu'il y a connaissance de l'exitence de la | > classe de base et que certains feraient des bêtises avec. Mais dans le | > contexte actuel, à part le prof, personne ne sait l'existance de la | > classe de base. Il n'y a donc aucun risque. | | D'accord. | sinon, dans le cas où l'on envisage de dériver une classe dont on ne connait | au départ que l'interface, qu'est ce qu'il faut regarder pour savoir | quelles bêtises ne pas faire en la dérivant - outre avoir un destructeur | qui fait qque chose alors que le destructeur de la classe de base n'est pas | virtuel ?
Ne pas essayer de détruire l'objet avec un pointer sur la classe de base.
| Je vois une perfidie possible dans l'implémentation de la classe de base, ce | serait qu'elle utilise du RTTI dans une fction membre d'une façon malsaine
| et ne supporte pas que celui-ci soit le nom d'une classe dérivée. Ca donne | bien un moyen de pièger une classe contre tout héritier potentiel (et là, | même sans utilisation polymorphique) non ?
C++ ne te protège pas de Machiavel, nous sommes d'accord.
| est-ce qu'il y a d'autres pièges moins hypothetiques ? | | si tu me donnes un référence pour aller me rafraîchir les idées sur ce sujet | je serais pleinement satisfait
Des références sur ?
[...]
| Comme ça la prochaine fois que je voudrai dériver une classe non prévue | pour, je saurai quoi vérifier au préalable.
Si la documentation dit « DO NOT DERIVE FROM THIS CLASS!!!! », alors ne le fais pas. Sinon, tu le fais avec une utilisation raisonable, tu ne devrais pas avoir de problème. Désolé, je n'ai pas de formule « close » pour déterminer quand quelque chose est raisonnable :-/
| > Quelle est la dernière fois que tu as fais des bêtises avec | > std::_Vector_base et std::vector à cause de la dérivation ? | | ça ne m'est jamais arrivé :) | mais ces 2 classes ont été écrites pour collaborer, donc c'est qd même la | moindre des choses
Dans ce cas, on ne devrait pas avoir l'héritage multiple ;-)
-- Gaby
Samuel Krempp
le Sunday 15 February 2004 16:46, écrivit :
| Comme ça la prochaine fois que je voudrai dériver une classe non prévue | pour, je saurai quoi vérifier au préalable.
Si la documentation dit « DO NOT DERIVE FROM THIS CLASS!!!! », alors ne le fais pas. Sinon, tu le fais avec une utilisation raisonable, tu ne devrais pas avoir de problème. Désolé, je n'ai pas de formule « close » pour déterminer quand quelque chose est raisonnable :-/
ça me suffit !
-- Sam
le Sunday 15 February 2004 16:46, gdr@cs.tamu.edu écrivit :
| Comme ça la prochaine fois que je voudrai dériver une classe non prévue
| pour, je saurai quoi vérifier au préalable.
Si la documentation dit « DO NOT DERIVE FROM THIS CLASS!!!! », alors
ne le fais pas. Sinon, tu le fais avec une utilisation raisonable, tu
ne devrais pas avoir de problème. Désolé, je n'ai pas de formule
« close » pour déterminer quand quelque chose est raisonnable :-/
| Comme ça la prochaine fois que je voudrai dériver une classe non prévue | pour, je saurai quoi vérifier au préalable.
Si la documentation dit « DO NOT DERIVE FROM THIS CLASS!!!! », alors ne le fais pas. Sinon, tu le fais avec une utilisation raisonable, tu ne devrais pas avoir de problème. Désolé, je n'ai pas de formule « close » pour déterminer quand quelque chose est raisonnable :-/
