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?
pour la sémantique, ce qu' "évoque" une égalité reste "uni"que; le fait que nous faisons correspondre à plusieurs entités (2/4 et 1/2 ou 5dm et 0.5m) la même réalité, quantité ou sentiment ne change pas cela. vérifier une égalité peut être fait de mille façons (et peux comparer des choses différentes) mais cela ne change pas la sa nature (identité) et à chaque fois vous direz bien "c'est égal" (ou pas).
Et bien non. 2/4 n'est pas égal à 1/2, et je ne dirais jamais le contraire. Je ne sais pas ce qu'est la réalité, mais mathématiquement, ce sont deux objets différents.
-- Loïc
pour la sémantique, ce qu' "évoque" une égalité reste "uni"que; le fait
que nous faisons correspondre à plusieurs entités (2/4 et 1/2 ou 5dm et
0.5m) la même réalité, quantité ou sentiment ne change pas cela.
vérifier une égalité peut être fait de mille façons (et peux comparer
des choses différentes) mais cela ne change pas la sa nature (identité)
et à chaque fois vous direz bien "c'est égal" (ou pas).
Et bien non. 2/4 n'est pas égal à 1/2, et je ne dirais jamais le
contraire. Je ne sais pas ce qu'est la réalité, mais mathématiquement,
ce sont deux objets différents.
pour la sémantique, ce qu' "évoque" une égalité reste "uni"que; le fait que nous faisons correspondre à plusieurs entités (2/4 et 1/2 ou 5dm et 0.5m) la même réalité, quantité ou sentiment ne change pas cela. vérifier une égalité peut être fait de mille façons (et peux comparer des choses différentes) mais cela ne change pas la sa nature (identité) et à chaque fois vous direz bien "c'est égal" (ou pas).
Et bien non. 2/4 n'est pas égal à 1/2, et je ne dirais jamais le contraire. Je ne sais pas ce qu'est la réalité, mais mathématiquement, ce sont deux objets différents.
-- Loïc
Gabriel Dos Reis
Sylvain writes:
| Gabriel Dos Reis wrote on 11/09/2006 04:21: | > Sylvain writes: | > | Gabriel Dos Reis wrote on 10/09/2006 22:29: | > | > Sylvain writes: | > | > | Franck Branjonneau wrote on 02/09/2006 23:36: | > | > | > | > | > | >> "==" est univoque | > | > | > Non. | > | > | | tu fais bien de ne pas détailler, ça évite les bourdes. | > | > | (si '0' n'est plus égal à '0' et '1' à '1' on cours au pb). | > | > volatile int x = 0; | > | > assert (x == x); | > | > ? | > | | un code débile pourquoi ? | > disons qu'il ne fait que te suivre en la matière. | | certes Gabriel, mais pourquoi tout ce bavardage, tu aurais pu nous | servir: [1] | | a ?= b; | donc Sylvain est un con.
Je savais que tu le ferais alors je n'ai pas voulu te griller la politesse.
-- Gaby
Sylvain <noSpam@mail.net> writes:
| Gabriel Dos Reis wrote on 11/09/2006 04:21:
| > Sylvain <noSpam@mail.net> writes:
| > | Gabriel Dos Reis wrote on 10/09/2006 22:29:
| > | > Sylvain <noSpam@mail.net> writes:
| > | > | Franck Branjonneau wrote on 02/09/2006 23:36:
| > | > | >
| > | > | >> "==" est univoque
| > | > | > Non.
| > | > | | tu fais bien de ne pas détailler, ça évite les bourdes.
| > | > | (si '0' n'est plus égal à '0' et '1' à '1' on cours au pb).
| > | > volatile int x = 0;
| > | > assert (x == x);
| > | > ?
| > | | un code débile pourquoi ?
| > disons qu'il ne fait que te suivre en la matière.
|
| certes Gabriel, mais pourquoi tout ce bavardage, tu aurais pu nous
| servir: [1]
|
| a ?= b;
| donc Sylvain est un con.
Je savais que tu le ferais alors je n'ai pas voulu te griller la
politesse.
| Gabriel Dos Reis wrote on 11/09/2006 04:21: | > Sylvain writes: | > | Gabriel Dos Reis wrote on 10/09/2006 22:29: | > | > Sylvain writes: | > | > | Franck Branjonneau wrote on 02/09/2006 23:36: | > | > | > | > | > | >> "==" est univoque | > | > | > Non. | > | > | | tu fais bien de ne pas détailler, ça évite les bourdes. | > | > | (si '0' n'est plus égal à '0' et '1' à '1' on cours au pb). | > | > volatile int x = 0; | > | > assert (x == x); | > | > ? | > | | un code débile pourquoi ? | > disons qu'il ne fait que te suivre en la matière. | | certes Gabriel, mais pourquoi tout ce bavardage, tu aurais pu nous | servir: [1] | | a ?= b; | donc Sylvain est un con.
Je savais que tu le ferais alors je n'ai pas voulu te griller la politesse.
-- Gaby
Marc Boyer
Le 11-09-2006, Sylvain a écrit :
Marc Boyer wrote on 11/09/2006 15:45:
- on a déjà indiqué que le problème du padding peut être réglé par une mise à zéro de toute la zone mémoire de la struct avant la recopie.
Oui, on ajoute des contraintes sur l'opérateur de copie pour régler le problème de l'opérateur de comparaison.
c'est un choix de consistance.
soit on pense que c'est déjà le souk avec une opérateur de copie ("qui existe toujours") et on ne change rien qui permettrait un opérateur de comparaison ("qui n'existera jamais").
Pour ma part, je me garderais bien de m'avancer sur ce qui existera un jour et ce qui n'existera jamais en C++.
Sinon, dans "The C rationale", on trouve §6.5.9: "The C89 Committee considered, on more that one occasion, permiting comparison of structures for equality. Such proposal founderer on the problem of holes in structures. A byte-wise comparison of the two structures would require that thye holes assuredly to be set to zero so taht all holes would compare equal, a difficult task for automatic or dynamically allocated variables. The possibility of union-type element in a structure raises insuperable problems with this approach".
Ce qui souligne que j'avais oublié les unions... union U { long double d; char c; }; struct S { int i; U u; };
Oui, mais un autre intervenant n'a-t-il pas souligné que la comparaison de deux NaN, même égaux bits à bit, devait être évaluée comme fausse ?
merci de le citer !!! lui (nous) répondre pourquoi aurait été encore plus sympa; pour ma part je ne peux pas reproduire son résultat et je ne l'explique pas; je le tiens, en l'état actuel, pour une erreur de son compilo .
Pour ma part, ce serait la norme qui ferait foi. Mais je n'ai pas la norme C++. Par contre (après moultes recherches), la norme C (§F.8.3) nous dit explicitement que "The statement x == x is false if x is a NaN". Je pense que par compatibilité, C++ doit demander la même chose.
Et puis il y a aussi les attributs *mutable*, qu'il va falloir ignorer.
ah, volatile, mutable, à qui le prochain ??
Ben c'est un peu le pb de C++: le langage est vaste, et une solution doit s'adapter à l'ensemble, pas à la sous partie à laquelle on avait pensé au début.
rappelle-moi, ou corrige moi si besoin, un attribut "mutable" est un machin qui a le droit de changer de valeur dans un contexte const, non ?
Dans les limites de mes connaissances, oui.
cela ne concerne que le compilo et les contrôles qu'il fera sur l'accès à cette variable - en aucun cas la façon dont elle sera mappée en mémoire (comme sa non prise en compte dans un sizeof, ou "ailleurs" non contiguë aux autres données).
quel rapport donc entre ce mutable et le fait que 2 instances ayant tous leurs champs égaux (bit à bit) seront égales tandis que si elles différent par la valeur d'un champ, même marqué mutable, elles seront vues différentes ???
Ben, souvent, le 'mutable' est une sorte de cache, ou un truc pour faire des stats, une sorte de 'truc en plus'. Et dans les cas pratiques que j'ai vu, l'égalité sémantique demande à ne pas prendre en compte l'attribut mutable.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 11-09-2006, Sylvain <noSpam@mail.net> a écrit :
Marc Boyer wrote on 11/09/2006 15:45:
- on a déjà indiqué que le problème du padding peut être réglé par une
mise à zéro de toute la zone mémoire de la struct avant la recopie.
Oui, on ajoute des contraintes sur l'opérateur de copie pour régler
le problème de l'opérateur de comparaison.
c'est un choix de consistance.
soit on pense que c'est déjà le souk avec une opérateur de copie ("qui
existe toujours") et on ne change rien qui permettrait un opérateur de
comparaison ("qui n'existera jamais").
Pour ma part, je me garderais bien de m'avancer sur ce qui
existera un jour et ce qui n'existera jamais en C++.
Sinon, dans "The C rationale", on trouve §6.5.9: "The C89 Committee
considered, on more that one occasion, permiting comparison of
structures for equality. Such proposal founderer on the problem
of holes in structures. A byte-wise comparison of the two structures
would require that thye holes assuredly to be set to zero
so taht all holes would compare equal, a difficult task for automatic
or dynamically allocated variables. The possibility of union-type
element in a structure raises insuperable problems with this approach".
Ce qui souligne que j'avais oublié les unions...
union U {
long double d;
char c;
};
struct S {
int i;
U u;
};
Oui, mais un autre intervenant n'a-t-il pas souligné que la
comparaison de deux NaN, même égaux bits à bit, devait être
évaluée comme fausse ?
merci de le citer !!! lui (nous) répondre pourquoi aurait été encore
plus sympa; pour ma part je ne peux pas reproduire son résultat et je ne
l'explique pas; je le tiens, en l'état actuel, pour une erreur de son
compilo .
Pour ma part, ce serait la norme qui ferait foi. Mais je n'ai
pas la norme C++. Par contre (après moultes recherches), la norme
C (§F.8.3) nous dit explicitement que "The statement x == x is
false if x is a NaN". Je pense que par compatibilité, C++ doit
demander la même chose.
Et puis il y a aussi les attributs *mutable*, qu'il va falloir
ignorer.
ah, volatile, mutable, à qui le prochain ??
Ben c'est un peu le pb de C++: le langage est vaste, et une solution
doit s'adapter à l'ensemble, pas à la sous partie à laquelle on
avait pensé au début.
rappelle-moi, ou corrige moi si besoin, un attribut "mutable" est un
machin qui a le droit de changer de valeur dans un contexte const, non ?
Dans les limites de mes connaissances, oui.
cela ne concerne que le compilo et les contrôles qu'il fera sur l'accès
à cette variable - en aucun cas la façon dont elle sera mappée en
mémoire (comme sa non prise en compte dans un sizeof, ou "ailleurs" non
contiguë aux autres données).
quel rapport donc entre ce mutable et le fait que 2 instances ayant tous
leurs champs égaux (bit à bit) seront égales tandis que si elles
différent par la valeur d'un champ, même marqué mutable, elles seront
vues différentes ???
Ben, souvent, le 'mutable' est une sorte de cache, ou un truc pour
faire des stats, une sorte de 'truc en plus'. Et dans les cas pratiques
que j'ai vu, l'égalité sémantique demande à ne pas prendre en compte
l'attribut mutable.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
- on a déjà indiqué que le problème du padding peut être réglé par une mise à zéro de toute la zone mémoire de la struct avant la recopie.
Oui, on ajoute des contraintes sur l'opérateur de copie pour régler le problème de l'opérateur de comparaison.
c'est un choix de consistance.
soit on pense que c'est déjà le souk avec une opérateur de copie ("qui existe toujours") et on ne change rien qui permettrait un opérateur de comparaison ("qui n'existera jamais").
Pour ma part, je me garderais bien de m'avancer sur ce qui existera un jour et ce qui n'existera jamais en C++.
Sinon, dans "The C rationale", on trouve §6.5.9: "The C89 Committee considered, on more that one occasion, permiting comparison of structures for equality. Such proposal founderer on the problem of holes in structures. A byte-wise comparison of the two structures would require that thye holes assuredly to be set to zero so taht all holes would compare equal, a difficult task for automatic or dynamically allocated variables. The possibility of union-type element in a structure raises insuperable problems with this approach".
Ce qui souligne que j'avais oublié les unions... union U { long double d; char c; }; struct S { int i; U u; };
Oui, mais un autre intervenant n'a-t-il pas souligné que la comparaison de deux NaN, même égaux bits à bit, devait être évaluée comme fausse ?
merci de le citer !!! lui (nous) répondre pourquoi aurait été encore plus sympa; pour ma part je ne peux pas reproduire son résultat et je ne l'explique pas; je le tiens, en l'état actuel, pour une erreur de son compilo .
Pour ma part, ce serait la norme qui ferait foi. Mais je n'ai pas la norme C++. Par contre (après moultes recherches), la norme C (§F.8.3) nous dit explicitement que "The statement x == x is false if x is a NaN". Je pense que par compatibilité, C++ doit demander la même chose.
Et puis il y a aussi les attributs *mutable*, qu'il va falloir ignorer.
ah, volatile, mutable, à qui le prochain ??
Ben c'est un peu le pb de C++: le langage est vaste, et une solution doit s'adapter à l'ensemble, pas à la sous partie à laquelle on avait pensé au début.
rappelle-moi, ou corrige moi si besoin, un attribut "mutable" est un machin qui a le droit de changer de valeur dans un contexte const, non ?
Dans les limites de mes connaissances, oui.
cela ne concerne que le compilo et les contrôles qu'il fera sur l'accès à cette variable - en aucun cas la façon dont elle sera mappée en mémoire (comme sa non prise en compte dans un sizeof, ou "ailleurs" non contiguë aux autres données).
quel rapport donc entre ce mutable et le fait que 2 instances ayant tous leurs champs égaux (bit à bit) seront égales tandis que si elles différent par la valeur d'un champ, même marqué mutable, elles seront vues différentes ???
Ben, souvent, le 'mutable' est une sorte de cache, ou un truc pour faire des stats, une sorte de 'truc en plus'. Et dans les cas pratiques que j'ai vu, l'égalité sémantique demande à ne pas prendre en compte l'attribut mutable.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Sylvain
Gabriel Dos Reis wrote on 12/09/2006 04:47:
Je savais que tu le ferais alors je n'ai pas voulu te griller la politesse.
c'est c'lllllla oui, passionnant dis donc !
Sylvain.
Gabriel Dos Reis wrote on 12/09/2006 04:47:
Je savais que tu le ferais alors je n'ai pas voulu te griller la
politesse.
