Le compilateur génére automatiquement certains opérateurs par défaut
pour les classes qui ne le font pas automatiquement.
Sauf erreur de ma part, il s'agit de:
- constructeur par défaut (Classe::Classe())
- constructeur de recopie (Classe::Classe(const Class&))
- affectation (Classe::operator = (const Classe&))
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par
exemple) de comparaison (==)?
L'implémentation naturelle serait de considérer ses attributs un à un,
tout comme pour la recopie.
Y a-t'il une raison?
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
A cause du padding (bourrage) entre champs ?
Marc Boyer PS: Pas de fu2 fclc++ car je ne pense pas que les explications dans l'un soient partinentes dans l'autre sur ce point. -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 02-09-2006, Olivier Croquette <ocroquette@ocroquette.free.fr> a écrit :
kanze wrote:
Pourquoi n'est-il pas prévu qu'il fasse de même pour
l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de
compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu
veux dire que le fournir aurait conduit à une incompatibilité avec le C?
En tout cas ma question est valable pour le C aussi. Pourquoi la norme
ne permet pas de comparer des structures comme il est possible de faire
des affectations?
A cause du padding (bourrage) entre champs ?
Marc Boyer
PS: Pas de fu2 fclc++ car je ne pense pas que les explications
dans l'un soient partinentes dans l'autre sur ce point.
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
Pourquoi n'est-il pas prévu qu'il fasse de même pour l'opérateur (par exemple) de comparaison (==)?
Parce que ce n'était pas nécessaire pour des raisons de compatibilité C.
Je ne comprends pas exactement ce que tu entends par là. Est-ce que tu veux dire que le fournir aurait conduit à une incompatibilité avec le C?
En tout cas ma question est valable pour le C aussi. Pourquoi la norme ne permet pas de comparer des structures comme il est possible de faire des affectations?
A cause du padding (bourrage) entre champs ?
Marc Boyer PS: Pas de fu2 fclc++ car je ne pense pas que les explications dans l'un soient partinentes dans l'autre sur ce point. -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
kanze
Sylvain wrote:
James a raison d'indiquer que -0 ne sera pas égal à +0, on peux aussi reboucler sur le fait qu'un float n'est (généralement) pas égal à lui-même (par utilisation de l'opérateur == ou par comparaison bit à bit) lorsque cette "même valeur" est issu de 2 déterminations différentes.
D'où est-ce que tu as trouvé ça ? Deux flottants peuvent ne pas être égaux, même quand ils sort de la même expression. De l'autre côté, si on sait travailler avec les flottants, on peut très bien arriver à des résultats précis. Surtout quand le résultat est 0.0.
mais si les structures impliquées ne contiennent pas de float, ou si encore, elles ne contiennent que des données alignées ("int" est assez courant comme type générique dans 99% des codes que je vois ici ou là) cette définition sera tout à fait convenable.
En somme, si la struct est assimilable à un tableau d'int, ça marche.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain wrote:
James a raison d'indiquer que -0 ne sera pas égal à +0, on
peux aussi reboucler sur le fait qu'un float n'est
(généralement) pas égal à lui-même (par utilisation de
l'opérateur == ou par comparaison bit à bit) lorsque cette
"même valeur" est issu de 2 déterminations différentes.
D'où est-ce que tu as trouvé ça ? Deux flottants peuvent ne pas
être égaux, même quand ils sort de la même expression. De
l'autre côté, si on sait travailler avec les flottants, on peut
très bien arriver à des résultats précis. Surtout quand le
résultat est 0.0.
mais si les structures impliquées ne contiennent pas de float,
ou si encore, elles ne contiennent que des données alignées
("int" est assez courant comme type générique dans 99% des
codes que je vois ici ou là) cette définition sera tout à fait
convenable.
En somme, si la struct est assimilable à un tableau d'int, ça
marche.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James a raison d'indiquer que -0 ne sera pas égal à +0, on peux aussi reboucler sur le fait qu'un float n'est (généralement) pas égal à lui-même (par utilisation de l'opérateur == ou par comparaison bit à bit) lorsque cette "même valeur" est issu de 2 déterminations différentes.
D'où est-ce que tu as trouvé ça ? Deux flottants peuvent ne pas être égaux, même quand ils sort de la même expression. De l'autre côté, si on sait travailler avec les flottants, on peut très bien arriver à des résultats précis. Surtout quand le résultat est 0.0.
mais si les structures impliquées ne contiennent pas de float, ou si encore, elles ne contiennent que des données alignées ("int" est assez courant comme type générique dans 99% des codes que je vois ici ou là) cette définition sera tout à fait convenable.
En somme, si la struct est assimilable à un tableau d'int, ça marche.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Sylvain wrote:
James Kanze wrote on 03/09/2006 14:20:
"==" est univoque alors qu'une relation d'ordre sur N champs ou de l'algèbre nécessite une définition de (quasi) groupe.
Bof. Il l'ont fait pour std::pair,
oui "bof" ! je n'ai pas dit que c'était compliqué mais que cela nécessite une loi que le compilo n'a pas à inventer lui-même.
De même que ==.
Je ne vois pas où il y a une grande différence entre == et <.
considère juste 2 pointeurs, "==" est vérifié s'ils contiennent la même adresse; ">" devrait faire quoi ? ordonner la valeurde cette adresse ? (seuls "==" et "!=" auraient un sens).
Et pour les flottants ? Selon certains, seulement les comparaisons d'inégalité aurait un sens.
Côté utilité, c'est l'opérateur < qu'il faut, même si la définition est arbitraire. Parce que c'est l'opérateur qu'utilise std::set, std::map, etc. Et parce que c'est l'opérateur où les débuttants se goure facilement.
Mais personnellement, je ne veux pas à avoir à modifier toutes mes classes pour supprimer un opérateur == non voulu.
"==" pourrait être implicite avec un (par exemple): typeof(a) == typeof(b) && memcmp(@a, @b, sizeof(a)) == 0
C-à-d donc qu'il ne fonctionnera de façon fiable qu'avec des objets qui ne comporte que des tableaux des unsigned char. Pas
pourquoi donc ???
Parce que dans tous les autres cas, il existe une possibilité des bits ou des bytes de rembourrage, qui peuvent prendre des valeurs indéfinies.
de types qui pourraient exiger du rembourrage,
ton sizeof ne marche pas avec des données paddées ??
C'est le memcmp qui ne marche pas avec les données dont les rembourrages prendent des valeurs arbitraires.
pas de type flottant, pas de pointeurs,
ton memcmp ne marche pas sur des octets contenant des float ? ou une adresse ?
Non. Il donne un résultat faux. Au moins sur certaines architectures, genre Intel, Sparc...
même pas des entiers signés, si on prétend encore que le C++ doit fonctionner sur des machines qui ne sont pas complément à deux.
je ne connais pas de compilo codant *le même nombre* parfois en complément à deux parfois pas; je ne vois pas non plus où un memcmp ne serait pas déterministe.
Oui, mais à part complément à deux, le zéro a deux représentations. Et memcmp peut renvoyer une valeur non-zéro même quand les valeurs sont égales.
Ça dépend, justement. Si le pointeur sert à la navigation, c'est probablement ce qu'on attend (au moins qu'on souhaite qu'il n'entre pas dans la comparaison du tout). Mais les objets qui navige, c'est plutôt rare que la comparaison ait un sens.
soit.
Où elle pourrait avoir un sens, c'est pour les objets de valeur, genre string, vector, etc. Et alors, s'il y a un pointeur, c'est que l'objet pointé fait partie de la valeur, et qu'il faut suivre le pointeur dans le comparaison.
tu veux dire comparer les valeurs contenu par l'objet pointé ? pas nécessairement.
si les 2 pointeurs contiennent la même adresse, la réponse est évidente; si elles différent, considérer les objets comme différents peut être acceptable (même si le contenu de ces pointeurs est égal).
Donc, si j'écris :
std::string a( "abc" ) ; std::string b( a ) ; if ( a == b ) ...
doit dépendre de l'implémentation de std::string.
ici la sémantique de comparaison touche ses limites actuelles: celle des pointeurs est de l'arithmétique e base (évaluation des adresses, non des contenus) celles des références est inexistantes.
pour comparaison, en Java avec String s1("toto") et String s2("toto"), on a bien s1 != s2 (ie "(s1 == s2)" évalué comme faux) au sens C++ on compare ici des adresses d'objects, donc obtenir le même résultat (false) d'évaluation ne serait pas troublant -- et encore une fois, la règle connue, le codeur définirait un opérateur idoine, si pour telle struct, il souhaite changer la règle en évaluant le contenu des données pointées.
Le Java n'est pas le C++. En Java, il n'y a pas de sémantique de valeur. Et l'opérateur == ne signifie pas l'égalité, mais l'identité. (On a une fonction membre isEqual pour l'égalité.)
Sauf pour certains types de base : le Java n'est pas particulièrement cohérent à cet égard.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain wrote:
James Kanze wrote on 03/09/2006 14:20:
"==" est univoque alors qu'une relation d'ordre sur N champs
ou de l'algèbre nécessite une définition de (quasi) groupe.
Bof. Il l'ont fait pour std::pair,
oui "bof" ! je n'ai pas dit que c'était compliqué mais que
cela nécessite une loi que le compilo n'a pas à inventer
lui-même.
De même que ==.
Je ne vois pas où il y a une grande différence entre == et <.
considère juste 2 pointeurs, "==" est vérifié s'ils
contiennent la même adresse; ">" devrait faire quoi ? ordonner
la valeurde cette adresse ? (seuls "==" et "!=" auraient un
sens).
Et pour les flottants ? Selon certains, seulement les
comparaisons d'inégalité aurait un sens.
Côté utilité, c'est l'opérateur < qu'il faut, même si la
définition est arbitraire. Parce que c'est l'opérateur
qu'utilise std::set, std::map, etc. Et parce que c'est
l'opérateur où les débuttants se goure facilement.
Mais personnellement, je ne veux pas à avoir à modifier toutes
mes classes pour supprimer un opérateur == non voulu.
"==" pourrait être implicite avec un (par exemple):
typeof(a) == typeof(b) && memcmp(@a, @b, sizeof(a)) == 0
C-à-d donc qu'il ne fonctionnera de façon fiable qu'avec des
objets qui ne comporte que des tableaux des unsigned char.
Pas
pourquoi donc ???
Parce que dans tous les autres cas, il existe une possibilité
des bits ou des bytes de rembourrage, qui peuvent prendre des
valeurs indéfinies.
de types qui pourraient exiger du rembourrage,
ton sizeof ne marche pas avec des données paddées ??
C'est le memcmp qui ne marche pas avec les données dont les
rembourrages prendent des valeurs arbitraires.
pas de type flottant, pas de pointeurs,
ton memcmp ne marche pas sur des octets contenant des float ?
ou une adresse ?
Non. Il donne un résultat faux. Au moins sur certaines
architectures, genre Intel, Sparc...
même pas des entiers signés, si on prétend encore
que le C++ doit fonctionner sur des machines qui
ne sont pas complément à deux.
je ne connais pas de compilo codant *le même nombre* parfois
en complément à deux parfois pas; je ne vois pas non plus où
un memcmp ne serait pas déterministe.
Oui, mais à part complément à deux, le zéro a deux
représentations. Et memcmp peut renvoyer une valeur non-zéro
même quand les valeurs sont égales.
Ça dépend, justement. Si le pointeur sert à la navigation,
c'est probablement ce qu'on attend (au moins qu'on souhaite
qu'il n'entre pas dans la comparaison du tout). Mais les
objets qui navige, c'est plutôt rare que la comparaison ait
un sens.
soit.
Où elle pourrait avoir un sens, c'est pour les objets de
valeur, genre string, vector, etc. Et alors, s'il y a un
pointeur, c'est que l'objet pointé fait partie de la valeur,
et qu'il faut suivre le pointeur dans le comparaison.
tu veux dire comparer les valeurs contenu par l'objet pointé ?
pas nécessairement.
si les 2 pointeurs contiennent la même adresse, la réponse est
évidente; si elles différent, considérer les objets comme
différents peut être acceptable (même si le contenu de ces
pointeurs est égal).
Donc, si j'écris :
std::string a( "abc" ) ;
std::string b( a ) ;
if ( a == b ) ...
doit dépendre de l'implémentation de std::string.
ici la sémantique de comparaison touche ses limites actuelles:
celle des pointeurs est de l'arithmétique e base (évaluation
des adresses, non des contenus) celles des références est
inexistantes.
pour comparaison, en Java avec String s1("toto") et String
s2("toto"), on a bien s1 != s2 (ie "(s1 == s2)" évalué comme
faux) au sens C++ on compare ici des adresses d'objects, donc
obtenir le même résultat (false) d'évaluation ne serait pas
troublant -- et encore une fois, la règle connue, le codeur
définirait un opérateur idoine, si pour telle struct, il
souhaite changer la règle en évaluant le contenu des données
pointées.
Le Java n'est pas le C++. En Java, il n'y a pas de sémantique de
valeur. Et l'opérateur == ne signifie pas l'égalité, mais
l'identité. (On a une fonction membre isEqual pour l'égalité.)
Sauf pour certains types de base : le Java n'est pas
particulièrement cohérent à cet égard.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"==" est univoque alors qu'une relation d'ordre sur N champs ou de l'algèbre nécessite une définition de (quasi) groupe.
Bof. Il l'ont fait pour std::pair,
oui "bof" ! je n'ai pas dit que c'était compliqué mais que cela nécessite une loi que le compilo n'a pas à inventer lui-même.
De même que ==.
Je ne vois pas où il y a une grande différence entre == et <.
considère juste 2 pointeurs, "==" est vérifié s'ils contiennent la même adresse; ">" devrait faire quoi ? ordonner la valeurde cette adresse ? (seuls "==" et "!=" auraient un sens).
Et pour les flottants ? Selon certains, seulement les comparaisons d'inégalité aurait un sens.
Côté utilité, c'est l'opérateur < qu'il faut, même si la définition est arbitraire. Parce que c'est l'opérateur qu'utilise std::set, std::map, etc. Et parce que c'est l'opérateur où les débuttants se goure facilement.
Mais personnellement, je ne veux pas à avoir à modifier toutes mes classes pour supprimer un opérateur == non voulu.
"==" pourrait être implicite avec un (par exemple): typeof(a) == typeof(b) && memcmp(@a, @b, sizeof(a)) == 0
C-à-d donc qu'il ne fonctionnera de façon fiable qu'avec des objets qui ne comporte que des tableaux des unsigned char. Pas
pourquoi donc ???
Parce que dans tous les autres cas, il existe une possibilité des bits ou des bytes de rembourrage, qui peuvent prendre des valeurs indéfinies.
de types qui pourraient exiger du rembourrage,
ton sizeof ne marche pas avec des données paddées ??
C'est le memcmp qui ne marche pas avec les données dont les rembourrages prendent des valeurs arbitraires.
pas de type flottant, pas de pointeurs,
ton memcmp ne marche pas sur des octets contenant des float ? ou une adresse ?
Non. Il donne un résultat faux. Au moins sur certaines architectures, genre Intel, Sparc...
même pas des entiers signés, si on prétend encore que le C++ doit fonctionner sur des machines qui ne sont pas complément à deux.
je ne connais pas de compilo codant *le même nombre* parfois en complément à deux parfois pas; je ne vois pas non plus où un memcmp ne serait pas déterministe.
Oui, mais à part complément à deux, le zéro a deux représentations. Et memcmp peut renvoyer une valeur non-zéro même quand les valeurs sont égales.
Ça dépend, justement. Si le pointeur sert à la navigation, c'est probablement ce qu'on attend (au moins qu'on souhaite qu'il n'entre pas dans la comparaison du tout). Mais les objets qui navige, c'est plutôt rare que la comparaison ait un sens.
soit.
Où elle pourrait avoir un sens, c'est pour les objets de valeur, genre string, vector, etc. Et alors, s'il y a un pointeur, c'est que l'objet pointé fait partie de la valeur, et qu'il faut suivre le pointeur dans le comparaison.
tu veux dire comparer les valeurs contenu par l'objet pointé ? pas nécessairement.
si les 2 pointeurs contiennent la même adresse, la réponse est évidente; si elles différent, considérer les objets comme différents peut être acceptable (même si le contenu de ces pointeurs est égal).
Donc, si j'écris :
std::string a( "abc" ) ; std::string b( a ) ; if ( a == b ) ...
doit dépendre de l'implémentation de std::string.
ici la sémantique de comparaison touche ses limites actuelles: celle des pointeurs est de l'arithmétique e base (évaluation des adresses, non des contenus) celles des références est inexistantes.
pour comparaison, en Java avec String s1("toto") et String s2("toto"), on a bien s1 != s2 (ie "(s1 == s2)" évalué comme faux) au sens C++ on compare ici des adresses d'objects, donc obtenir le même résultat (false) d'évaluation ne serait pas troublant -- et encore une fois, la règle connue, le codeur définirait un opérateur idoine, si pour telle struct, il souhaite changer la règle en évaluant le contenu des données pointées.
Le Java n'est pas le C++. En Java, il n'y a pas de sémantique de valeur. Et l'opérateur == ne signifie pas l'égalité, mais l'identité. (On a une fonction membre isEqual pour l'égalité.)
Sauf pour certains types de base : le Java n'est pas particulièrement cohérent à cet égard.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard
pour comparaison, en Java avec String s1("toto") et String s2("toto"), on a bien s1 != s2 (ie "(s1 == s2)" évalué comme faux) au sens C++ on compare ici des adresses d'objects, donc obtenir le même résultat (false) d'évaluation ne serait pas troublant -- et encore une fois, la règle connue, le codeur définirait un opérateur idoine, si pour telle struct, il souhaite changer la règle en évaluant le contenu des données pointées.
Le Java n'est pas le C++. En Java, il n'y a pas de sémantique de valeur.
C'est bien ce qu'a voulu dire Sylvain non ? "on compare ici des adresses d'objects"
Et l'opérateur == ne signifie pas l'égalité, mais l'identité. (On a une fonction membre isEqual pour l'égalité.)
C'est equals :-)
Sauf pour certains types de base : le Java n'est pas particulièrement cohérent à cet égard.
Ah ce Java....
-- Alain
pour comparaison, en Java avec String s1("toto") et String
s2("toto"), on a bien s1 != s2 (ie "(s1 == s2)" évalué comme
faux) au sens C++ on compare ici des adresses d'objects, donc
obtenir le même résultat (false) d'évaluation ne serait pas
troublant -- et encore une fois, la règle connue, le codeur
définirait un opérateur idoine, si pour telle struct, il
souhaite changer la règle en évaluant le contenu des données
pointées.
Le Java n'est pas le C++. En Java, il n'y a pas de sémantique de
valeur.
C'est bien ce qu'a voulu dire Sylvain non ? "on compare ici des adresses
d'objects"
Et l'opérateur == ne signifie pas l'égalité, mais
l'identité. (On a une fonction membre isEqual pour l'égalité.)
C'est equals :-)
Sauf pour certains types de base : le Java n'est pas
particulièrement cohérent à cet égard.
pour comparaison, en Java avec String s1("toto") et String s2("toto"), on a bien s1 != s2 (ie "(s1 == s2)" évalué comme faux) au sens C++ on compare ici des adresses d'objects, donc obtenir le même résultat (false) d'évaluation ne serait pas troublant -- et encore une fois, la règle connue, le codeur définirait un opérateur idoine, si pour telle struct, il souhaite changer la règle en évaluant le contenu des données pointées.
Le Java n'est pas le C++. En Java, il n'y a pas de sémantique de valeur.
C'est bien ce qu'a voulu dire Sylvain non ? "on compare ici des adresses d'objects"
Et l'opérateur == ne signifie pas l'égalité, mais l'identité. (On a une fonction membre isEqual pour l'égalité.)
C'est equals :-)
Sauf pour certains types de base : le Java n'est pas particulièrement cohérent à cet égard.
Ah ce Java....
-- Alain
Sylvain
kanze wrote on 04/09/2006 09:26:
[...] il reste le problème des octets d'alignement qui s'autorisent à être n'importe quoi (non initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de plate-formes, et qu'ils permettent de meilleurs performances sur d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas faire l'effort de les initialiser".
Sylvain.
kanze wrote on 04/09/2006 09:26:
[...] il reste le problème des octets
d'alignement qui s'autorisent à être n'importe quoi (non
initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de
plate-formes, et qu'ils permettent de meilleurs performances sur
d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas
faire l'effort de les initialiser".
[...] il reste le problème des octets d'alignement qui s'autorisent à être n'importe quoi (non initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de plate-formes, et qu'ils permettent de meilleurs performances sur d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas faire l'effort de les initialiser".
Sylvain.
kanze
Sylvain wrote:
kanze wrote on 04/09/2006 09:26:
[...] il reste le problème des octets d'alignement qui s'autorisent à être n'importe quoi (non initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de plate-formes, et qu'ils permettent de meilleurs performances sur d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas faire l'effort de les initialiser".
Tu n'as pas l'air de comprendre très bien. Comment fais-tu pour t'assurer qu'ils ont toujours la valeur voulue ? Étant donné que dans certains cas, le compilateur génère du code qui les modifie, avec des valeurs aléatoires.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain wrote:
kanze wrote on 04/09/2006 09:26:
[...] il reste le problème des octets
d'alignement qui s'autorisent à être n'importe quoi (non
initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de
plate-formes, et qu'ils permettent de meilleurs performances sur
d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable
de ne pas faire l'effort de les initialiser".
Tu n'as pas l'air de comprendre très bien. Comment fais-tu pour
t'assurer qu'ils ont toujours la valeur voulue ? Étant donné
que dans certains cas, le compilateur génère du code qui les
modifie, avec des valeurs aléatoires.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[...] il reste le problème des octets d'alignement qui s'autorisent à être n'importe quoi (non initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de plate-formes, et qu'ils permettent de meilleurs performances sur d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas faire l'effort de les initialiser".
Tu n'as pas l'air de comprendre très bien. Comment fais-tu pour t'assurer qu'ils ont toujours la valeur voulue ? Étant donné que dans certains cas, le compilateur génère du code qui les modifie, avec des valeurs aléatoires.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain
kanze wrote on 05/09/2006 09:53:
Sylvain wrote:
kanze wrote on 04/09/2006 09:26:
[...] il reste le problème des octets d'alignement qui s'autorisent à être n'importe quoi (non initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de plate-formes, et qu'ils permettent de meilleurs performances sur d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas faire l'effort de les initialiser".
Tu n'as pas l'air de comprendre très bien. Comment fais-tu pour t'assurer qu'ils ont toujours la valeur voulue ? Étant donné que dans certains cas, le compilateur génère du code qui les modifie, avec des valeurs aléatoires.
ce n'est toujours pas ma question. (mais je note que "dans certains cas" .....)
Sylvain.
kanze wrote on 05/09/2006 09:53:
Sylvain wrote:
kanze wrote on 04/09/2006 09:26:
[...] il reste le problème des octets
d'alignement qui s'autorisent à être n'importe quoi (non
initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de
plate-formes, et qu'ils permettent de meilleurs performances sur
d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable
de ne pas faire l'effort de les initialiser".
Tu n'as pas l'air de comprendre très bien. Comment fais-tu pour
t'assurer qu'ils ont toujours la valeur voulue ? Étant donné
que dans certains cas, le compilateur génère du code qui les
modifie, avec des valeurs aléatoires.
ce n'est toujours pas ma question.
(mais je note que "dans certains cas" .....)
[...] il reste le problème des octets d'alignement qui s'autorisent à être n'importe quoi (non initialisé); la norme tient tant à ce bruit là?
Plutôt, étant donné qu'ils sont nécessaires sur beaucoup de plate-formes, et qu'ils permettent de meilleurs performances sur d'autres.
la question n'est pas "servent-ils" mais "est-il indispensable de ne pas faire l'effort de les initialiser".
Tu n'as pas l'air de comprendre très bien. Comment fais-tu pour t'assurer qu'ils ont toujours la valeur voulue ? Étant donné que dans certains cas, le compilateur génère du code qui les modifie, avec des valeurs aléatoires.
ce n'est toujours pas ma question. (mais je note que "dans certains cas" .....)
Sylvain.
kanze
Olivier Croquette wrote:
Loïc Joly wrote:
Si le fait qu'il soit par défaut est un si gros problème, alors que le développeur l'appelle explicitement dans un operator == défini à la main!
Le compilateur a toutes les informations nécessaires pour le faire, mais ne le permet pas, et c'est très gênant d'avoir à le faire autrement :(
C'est là un besoin assez différent que celui exprimé en premier, et qui me semble bien plus légitime.
Mon vrai besoin est de pouvoir faire une copie membre à membre automatique tout court.
C'est ce que fait le constructeur de copie et l'affectation générés automatiquement par le compilateur.
Qu'entends-tu par "le besoin exprimé en premier"?
Le "besoin exprimé en premier", c'était que le compilateur génère automatiquement l'operator==. Ce qui n'est pas une bonne idée. À vrai dire, ce n'est pas superbe non plus que le compilateur génère implicitement le constructeur de copie de l'affectation -- mais il faut le faire pour des raisons de compatibilité C.
Qu'il y ait en revanche un mechanisme pour dire au compilateur de générer ces opérateurs, ou d'autres, automatiquement dans le cas où on lui le démande explicitement, pourquoi pas ?
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Olivier Croquette wrote:
Loïc Joly wrote:
Si le fait qu'il soit par défaut est un si gros problème,
alors que le développeur l'appelle explicitement dans un
operator == défini à la main!
Le compilateur a toutes les informations nécessaires pour
le faire, mais ne le permet pas, et c'est très gênant
d'avoir à le faire autrement :(
C'est là un besoin assez différent que celui exprimé en
premier, et qui me semble bien plus légitime.
Mon vrai besoin est de pouvoir faire une copie membre à membre
automatique tout court.
C'est ce que fait le constructeur de copie et l'affectation
générés automatiquement par le compilateur.
Qu'entends-tu par "le besoin exprimé en premier"?
Le "besoin exprimé en premier", c'était que le compilateur
génère automatiquement l'operator==. Ce qui n'est pas une bonne
idée. À vrai dire, ce n'est pas superbe non plus que le
compilateur génère implicitement le constructeur de copie de
l'affectation -- mais il faut le faire pour des raisons de
compatibilité C.
Qu'il y ait en revanche un mechanisme pour dire au compilateur
de générer ces opérateurs, ou d'autres, automatiquement dans le
cas où on lui le démande explicitement, pourquoi pas ?
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Si le fait qu'il soit par défaut est un si gros problème, alors que le développeur l'appelle explicitement dans un operator == défini à la main!
Le compilateur a toutes les informations nécessaires pour le faire, mais ne le permet pas, et c'est très gênant d'avoir à le faire autrement :(
C'est là un besoin assez différent que celui exprimé en premier, et qui me semble bien plus légitime.
Mon vrai besoin est de pouvoir faire une copie membre à membre automatique tout court.
C'est ce que fait le constructeur de copie et l'affectation générés automatiquement par le compilateur.
Qu'entends-tu par "le besoin exprimé en premier"?
Le "besoin exprimé en premier", c'était que le compilateur génère automatiquement l'operator==. Ce qui n'est pas une bonne idée. À vrai dire, ce n'est pas superbe non plus que le compilateur génère implicitement le constructeur de copie de l'affectation -- mais il faut le faire pour des raisons de compatibilité C.
Qu'il y ait en revanche un mechanisme pour dire au compilateur de générer ces opérateurs, ou d'autres, automatiquement dans le cas où on lui le démande explicitement, pourquoi pas ?
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Serge Paccalin
Qu'il y ait en revanche un mechanisme pour dire au compilateur de générer ces opérateurs, ou d'autres, automatiquement dans le cas où on lui le démande explicitement, pourquoi pas ?
Qu'il y ait en revanche un mechanisme pour dire au compilateur
de générer ces opérateurs, ou d'autres, automatiquement dans le
cas où on lui le démande explicitement, pourquoi pas ?
Qu'il y ait en revanche un mechanisme pour dire au compilateur de générer ces opérateurs, ou d'autres, automatiquement dans le cas où on lui le démande explicitement, pourquoi pas ?
Qu'il y ait en revanche un mechanisme pour dire au compilateur de générer ces opérateurs, ou d'autres, automatiquement dans le cas où on lui le démande explicitement, pourquoi pas ?
Je sais qu'un des membres du comité s'est intéressé à la possibilité de déclarer qu'on veut avoir tel ou tel opérateur par défaut, mais avec des conditions autres ce qu'on aurait par défaut : le destructeur par défaut, par exemple, mais virtuel, ou le constructeur par défaut, mais protégé (et aussi dans le cas où on aurait déclaré d'autres constructeurs). Mais je ne sais pas où il en est, nir le contenu exact des propositions.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Serge Paccalin wrote:
Qu'il y ait en revanche un mechanisme pour dire au compilateur
de générer ces opérateurs, ou d'autres, automatiquement dans le
cas où on lui le démande explicitement, pourquoi pas ?
Je sais qu'un des membres du comité s'est intéressé à la
possibilité de déclarer qu'on veut avoir tel ou tel opérateur
par défaut, mais avec des conditions autres ce qu'on aurait par
défaut : le destructeur par défaut, par exemple, mais virtuel,
ou le constructeur par défaut, mais protégé (et aussi dans le
cas où on aurait déclaré d'autres constructeurs). Mais je ne
sais pas où il en est, nir le contenu exact des propositions.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Qu'il y ait en revanche un mechanisme pour dire au compilateur de générer ces opérateurs, ou d'autres, automatiquement dans le cas où on lui le démande explicitement, pourquoi pas ?
Je sais qu'un des membres du comité s'est intéressé à la possibilité de déclarer qu'on veut avoir tel ou tel opérateur par défaut, mais avec des conditions autres ce qu'on aurait par défaut : le destructeur par défaut, par exemple, mais virtuel, ou le constructeur par défaut, mais protégé (et aussi dans le cas où on aurait déclaré d'autres constructeurs). Mais je ne sais pas où il en est, nir le contenu exact des propositions.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
