Est-ce que je dois écrire ++it au lieu de it++ ??
En fait, est-ce que je parcours bien (et détruit) tous les éléments de la
map en procédant de cette manière ?
Égal. En théorie, dans certains cas, ++it pourrait être plus performant, mais je n'ai jamais trouvé une différence mésurable. Sinon, c'est pareil au même.
C-à-d un comportement indéfini selon la norme, mais pas de problème en pratique.
Peux-tu préciser en quoi le comportement est indéfini ?
La norme dit que tous les objets dans une collection doivent être «@copiable » et « assignable ». Après le delete d'un objet, le pointeur n'est plus ni l'un ni l'autre. Donc, formelement, tu as un comportement indéfini. Pour éviter le comportement indéfini, il faudrait mettre le pointeur à null immédiatement, ou supprimer l'entrée dans la collection avant de faire le delete.
Pratiquement, évidemment, la collection ne va pas copier ni affecter l'objet sans raison -- donc, si tu n'y accèdes pas, il va pas y avoir de problème. Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
C'est pour ça que le problème est pûrement théorique.
-- James Kanze GABI Software mailto: 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
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bpgv6s$kd2$1@news-reader4.wanadoo.fr>...
kanze@gabi-soft.fr wrote:
Est-ce que je dois écrire ++it au lieu de it++ ??
Égal. En théorie, dans certains cas, ++it pourrait être plus
performant, mais je n'ai jamais trouvé une différence mésurable.
Sinon, c'est pareil au même.
C-à-d un comportement indéfini selon la norme, mais pas de problème
en pratique.
Peux-tu préciser en quoi le comportement est indéfini ?
La norme dit que tous les objets dans une collection doivent être
«@copiable » et « assignable ». Après le delete d'un objet, le pointeur
n'est plus ni l'un ni l'autre. Donc, formelement, tu as un comportement
indéfini. Pour éviter le comportement indéfini, il faudrait mettre le
pointeur à null immédiatement, ou supprimer l'entrée dans la collection
avant de faire le delete.
Pratiquement, évidemment, la collection ne va pas copier ni affecter
l'objet sans raison -- donc, si tu n'y accèdes pas, il va pas y avoir de
problème. Pratiquement, aussi, je ne connais pas de plateforme
aujourd'hui où simplement accéder à un pointeur invalid pose un
problème.
C'est pour ça que le problème est pûrement théorique.
--
James Kanze GABI Software mailto:kanze@gabi-soft.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
Égal. En théorie, dans certains cas, ++it pourrait être plus performant, mais je n'ai jamais trouvé une différence mésurable. Sinon, c'est pareil au même.
C-à-d un comportement indéfini selon la norme, mais pas de problème en pratique.
Peux-tu préciser en quoi le comportement est indéfini ?
La norme dit que tous les objets dans une collection doivent être «@copiable » et « assignable ». Après le delete d'un objet, le pointeur n'est plus ni l'un ni l'autre. Donc, formelement, tu as un comportement indéfini. Pour éviter le comportement indéfini, il faudrait mettre le pointeur à null immédiatement, ou supprimer l'entrée dans la collection avant de faire le delete.
Pratiquement, évidemment, la collection ne va pas copier ni affecter l'objet sans raison -- donc, si tu n'y accèdes pas, il va pas y avoir de problème. Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
C'est pour ça que le problème est pûrement théorique.
-- James Kanze GABI Software mailto: 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
kanze
Loïc Joly wrote in message news:<bpgv6s$kd2$...
wrote:
Est-ce que je dois écrire ++it au lieu de it++ ??
Égal. En théorie, dans certains cas, ++it pourrait être plus performant, mais je n'ai jamais trouvé une différence mésurable. Sinon, c'est pareil au même.
C-à-d un comportement indéfini selon la norme, mais pas de problème en pratique.
Peux-tu préciser en quoi le comportement est indéfini ?
La norme dit que tous les objets dans une collection doivent être «@copiable » et « assignable ». Après le delete d'un objet, le pointeur n'est plus ni l'un ni l'autre. Donc, formelement, tu as un comportement indéfini. Pour éviter le comportement indéfini, il faudrait mettre le pointeur à null immédiatement, ou supprimer l'entrée dans la collection avant de faire le delete.
Pratiquement, évidemment, la collection ne va pas copier ni affecter l'objet sans raison -- donc, si tu n'y accèdes pas, il va pas y avoir de problème. Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
C'est pour ça que le problème est pûrement théorique.
-- James Kanze GABI Software mailto: 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
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<bpgv6s$kd2$1@news-reader4.wanadoo.fr>...
kanze@gabi-soft.fr wrote:
Est-ce que je dois écrire ++it au lieu de it++ ??
Égal. En théorie, dans certains cas, ++it pourrait être plus
performant, mais je n'ai jamais trouvé une différence mésurable.
Sinon, c'est pareil au même.
C-à-d un comportement indéfini selon la norme, mais pas de problème
en pratique.
Peux-tu préciser en quoi le comportement est indéfini ?
La norme dit que tous les objets dans une collection doivent être
«@copiable » et « assignable ». Après le delete d'un objet, le pointeur
n'est plus ni l'un ni l'autre. Donc, formelement, tu as un comportement
indéfini. Pour éviter le comportement indéfini, il faudrait mettre le
pointeur à null immédiatement, ou supprimer l'entrée dans la collection
avant de faire le delete.
Pratiquement, évidemment, la collection ne va pas copier ni affecter
l'objet sans raison -- donc, si tu n'y accèdes pas, il va pas y avoir de
problème. Pratiquement, aussi, je ne connais pas de plateforme
aujourd'hui où simplement accéder à un pointeur invalid pose un
problème.
C'est pour ça que le problème est pûrement théorique.
--
James Kanze GABI Software mailto:kanze@gabi-soft.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
Égal. En théorie, dans certains cas, ++it pourrait être plus performant, mais je n'ai jamais trouvé une différence mésurable. Sinon, c'est pareil au même.
C-à-d un comportement indéfini selon la norme, mais pas de problème en pratique.
Peux-tu préciser en quoi le comportement est indéfini ?
La norme dit que tous les objets dans une collection doivent être «@copiable » et « assignable ». Après le delete d'un objet, le pointeur n'est plus ni l'un ni l'autre. Donc, formelement, tu as un comportement indéfini. Pour éviter le comportement indéfini, il faudrait mettre le pointeur à null immédiatement, ou supprimer l'entrée dans la collection avant de faire le delete.
Pratiquement, évidemment, la collection ne va pas copier ni affecter l'objet sans raison -- donc, si tu n'y accèdes pas, il va pas y avoir de problème. Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
C'est pour ça que le problème est pûrement théorique.
-- James Kanze GABI Software mailto: 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
Fabien LE LEZ
On 20 Nov 2003 01:01:21 -0800, wrote:
Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
Pourquoi avoir mis cette restriction dans la norme si elle ne sert nulle part ?
-- ;-)
On 20 Nov 2003 01:01:21 -0800, kanze@gabi-soft.fr wrote:
Pratiquement, aussi, je ne connais pas de plateforme
aujourd'hui où simplement accéder à un pointeur invalid pose un
problème.
Pourquoi avoir mis cette restriction dans la norme si elle ne sert
nulle part ?
Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
Pourquoi avoir mis cette restriction dans la norme si elle ne sert nulle part ?
-- ;-)
Jean-Marc Bourguet
Fabien LE LEZ writes:
On 20 Nov 2003 01:01:21 -0800, wrote:
Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
Pourquoi avoir mis cette restriction dans la norme si elle ne sert nulle part ?
Si j'ai bonne memoire, charger un segment invalide dans un registre de segment d'un 386 et au-dela provoque une interruption. C'est pas donc tout a fait artificiel comme restriction.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
On 20 Nov 2003 01:01:21 -0800, kanze@gabi-soft.fr wrote:
Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui
où simplement accéder à un pointeur invalid pose un problème.
Pourquoi avoir mis cette restriction dans la norme si elle ne sert
nulle part ?
Si j'ai bonne memoire, charger un segment invalide dans un registre de
segment d'un 386 et au-dela provoque une interruption. C'est pas donc
tout a fait artificiel comme restriction.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui où simplement accéder à un pointeur invalid pose un problème.
Pourquoi avoir mis cette restriction dans la norme si elle ne sert nulle part ?
Si j'ai bonne memoire, charger un segment invalide dans un registre de segment d'un 386 et au-dela provoque une interruption. C'est pas donc tout a fait artificiel comme restriction.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze
Fabien LE LEZ writes:
|> On 20 Nov 2003 01:01:21 -0800, wrote:
|> > Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui |> >où simplement accéder à un pointeur invalid pose un |> >problème.
|> Pourquoi avoir mis cette restriction dans la norme si elle ne sert |> nulle part ?
Laquelle des deux « restrictions » ?
La façon « intuitive » de copier un pointeur sur un 80286/80386, c'est bien de le charger avec LDS ou LES. Or, ces deux instructions chargent un régistre de segmentation, et si le segment n'est pas bon, provoque un trappe. À l'époque de la formulation de la norme C, il y avait aussi bien au moins un système d'exploitation qui gérer les allocations au niveau des segments, et qui invalidait le segment lors de la libération. La restriction qu'on ne peut pas accéder à un tel pointeur est valide ; à mon avis, il n'y a pas réelement de raison à le supprimer aujourd'hui.
L'autre restriction, c'est la règle qu'il faut toujours pouvoir copier l'objet dans la collection, or qu'on sait très bien qu'aucune implémentation ne copie sans raison. Dans ce cas-là, je crois que c'est simplement que le travail à spécifier quand on aurait droit à laisser un objet invalide dans la collection c'était trop élevé par rapport au gain perçu ; c'est une chose à dire que dans tel ou tel contexte, je sais que l'implémentation ne copie pas, et une autre à le spécifier avec la précision voulue dans une norme.
Quand je dis que l'opération en question est sans risques, malgré la norme, c'est en fait sur ce deuxième point que je me base -- si je fais quelque chose du genre :
for ( Collection::iterator i = c.begin(); i != c.end() ; ++ i ) { delete *i ; }
dans un destructeur, ou c est un membre (et donc, que la destruction de la collection suit immédiatement la boucle), je sais qu'aucune implémentation va lire les pointeurs par la suite -- c'est donc sans risque. Je ne compte pas sur le fait que lire les pointeurs est sans risque, même si c'est le cas sur les machines et sous les systèmes d'exploitation dont je me sers actuellement. Linux et Windows utilisent tous les deux un adressage linéaire sans segmentation sur les architectures Intel, mais je me suis déjà servi des systèmes d'exploitation où ce n'était pas le cas, et où la lecture d'un pointeur après un delete générait réelement une trappe (et où un void* était plus grand qu'un long).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Fabien LE LEZ <gramster@gramster.com> writes:
|> On 20 Nov 2003 01:01:21 -0800, kanze@gabi-soft.fr wrote:
|> > Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui
|> >où simplement accéder à un pointeur invalid pose un
|> >problème.
|> Pourquoi avoir mis cette restriction dans la norme si elle ne sert
|> nulle part ?
Laquelle des deux « restrictions » ?
La façon « intuitive » de copier un pointeur sur un
80286/80386, c'est bien de le charger avec LDS ou LES. Or, ces deux
instructions chargent un régistre de segmentation, et si le segment
n'est pas bon, provoque un trappe. À l'époque de la formulation de
la norme C, il y avait aussi bien au moins un système d'exploitation
qui gérer les allocations au niveau des segments, et qui invalidait
le segment lors de la libération. La restriction qu'on ne peut pas
accéder à un tel pointeur est valide ; à mon avis, il n'y a pas
réelement de raison à le supprimer aujourd'hui.
L'autre restriction, c'est la règle qu'il faut toujours pouvoir
copier l'objet dans la collection, or qu'on sait très bien qu'aucune
implémentation ne copie sans raison. Dans ce cas-là, je crois que
c'est simplement que le travail à spécifier quand on aurait droit
à laisser un objet invalide dans la collection c'était trop
élevé par rapport au gain perçu ; c'est une chose à dire que
dans tel ou tel contexte, je sais que l'implémentation ne copie pas,
et une autre à le spécifier avec la précision voulue dans une
norme.
Quand je dis que l'opération en question est sans risques, malgré
la norme, c'est en fait sur ce deuxième point que je me base -- si je
fais quelque chose du genre :
for ( Collection::iterator i = c.begin(); i != c.end() ; ++ i ) {
delete *i ;
}
dans un destructeur, ou c est un membre (et donc, que la destruction de
la collection suit immédiatement la boucle), je sais qu'aucune
implémentation va lire les pointeurs par la suite -- c'est donc sans
risque. Je ne compte pas sur le fait que lire les pointeurs est sans
risque, même si c'est le cas sur les machines et sous les systèmes
d'exploitation dont je me sers actuellement. Linux et Windows utilisent
tous les deux un adressage linéaire sans segmentation sur les
architectures Intel, mais je me suis déjà servi des systèmes
d'exploitation où ce n'était pas le cas, et où la lecture d'un
pointeur après un delete générait réelement une trappe (et
où un void* était plus grand qu'un long).
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > Pratiquement, aussi, je ne connais pas de plateforme aujourd'hui |> >où simplement accéder à un pointeur invalid pose un |> >problème.
|> Pourquoi avoir mis cette restriction dans la norme si elle ne sert |> nulle part ?
Laquelle des deux « restrictions » ?
La façon « intuitive » de copier un pointeur sur un 80286/80386, c'est bien de le charger avec LDS ou LES. Or, ces deux instructions chargent un régistre de segmentation, et si le segment n'est pas bon, provoque un trappe. À l'époque de la formulation de la norme C, il y avait aussi bien au moins un système d'exploitation qui gérer les allocations au niveau des segments, et qui invalidait le segment lors de la libération. La restriction qu'on ne peut pas accéder à un tel pointeur est valide ; à mon avis, il n'y a pas réelement de raison à le supprimer aujourd'hui.
L'autre restriction, c'est la règle qu'il faut toujours pouvoir copier l'objet dans la collection, or qu'on sait très bien qu'aucune implémentation ne copie sans raison. Dans ce cas-là, je crois que c'est simplement que le travail à spécifier quand on aurait droit à laisser un objet invalide dans la collection c'était trop élevé par rapport au gain perçu ; c'est une chose à dire que dans tel ou tel contexte, je sais que l'implémentation ne copie pas, et une autre à le spécifier avec la précision voulue dans une norme.
Quand je dis que l'opération en question est sans risques, malgré la norme, c'est en fait sur ce deuxième point que je me base -- si je fais quelque chose du genre :
for ( Collection::iterator i = c.begin(); i != c.end() ; ++ i ) { delete *i ; }
dans un destructeur, ou c est un membre (et donc, que la destruction de la collection suit immédiatement la boucle), je sais qu'aucune implémentation va lire les pointeurs par la suite -- c'est donc sans risque. Je ne compte pas sur le fait que lire les pointeurs est sans risque, même si c'est le cas sur les machines et sous les systèmes d'exploitation dont je me sers actuellement. Linux et Windows utilisent tous les deux un adressage linéaire sans segmentation sur les architectures Intel, mais je me suis déjà servi des systèmes d'exploitation où ce n'était pas le cas, et où la lecture d'un pointeur après un delete générait réelement une trappe (et où un void* était plus grand qu'un long).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
