Pas d'operateur de comparaison par defaut

Sylvain <noSpam@mail.net> écrivait:

Franck Branjonneau wrote on 03/09/2006 01:02:

Mais '0' égale '0' et '0' == '0' ; c'est fixé par le langage.
Par contre, la sémantique de operator== ne l'est pas ; son utilisation
à d'autres fins que la représentation de l'égalité est
envisageable.

?! certes "==" peut servir à diviser par 3 les opérandes, mais je
pensais bien à un test d'égalité.

btw, la question ne portait pas sur la possibilité de "détourner" cet
opérateur, mais voulait utiliser son acceptation première.

Enfin, même quand "==" est "égaler" est-ce nécessairement la vraie
égalité -- la diagonale de TxT pour un type T ? En pratique, je pense
que non. Et en théorie :

c'est quoi la "diagonale" d'un type ?

La diagonale du produit cartésien de T par T : les couples (x,x) de TxT.

qu'est ce qui empêche ce compilo de traiter l'égalité entre 2
structs ?

Rien, pour autant que je sache. Mais c'est sans intérêt tant que la
sémantique de l'égalité n'est pas définie.

Celle que tu proposes correspond à son acception première. Mais par qui ?
Và dire à un physicien que 5 m n'est pas égal à 50 dm ; oui le
mathématicien à décidé de représenter les longueurs comme
des couples (valeur, unité) et (5, m) diffère bien de (50, dm).
Et l'acception courante de l'égalité est encore plus large :
«tous les hommes sont égaux» ou «Asafa Powell égale le record du monde
du 100 mètres» ou ...

Dans la plupart des cas (les miens), l'égalité de deux objets n'est
pas l'égalité de leur valeur -- je ne veux pas avoir à composer avec
un opérator== implicite qui ne m'est (presque) d'aucune utilité.

struct S {};

S s1, s2;
s1 == s2 est-il vrai ou faux ?

ce qui est en cause ici est l'initialisation des statiques (pas leur
comparaison, même si elle imposera qu'une initialisation
(déterministe) existe).

Un problème pratique.

Autre cas concret :

struct S { /* */ };
struct T: S { /* */ };

S s(/* */); T t(/* */);
s == t est-il vrai ou faux ?

--
Franck Branjonneau

Sylvain <noSpam@mail.net> écrivait:

Franck Branjonneau wrote on 03/09/2006 01:00:

C'est plus que raisonnable. Cependant, l'usage a montré qu'il valait mieux
déclarer un constructeur de copie privé plutôt que de le laisser en libre
accès lorsqu'il n'a pas de sens.

"un" usage à montré ... 'ma' pratique me montre que je n'ai pas à
perdre mon temps à alourdir mes codes avec ces cadenas puisque je, et
mes utilisateurs, ne faisons pas ce que nous ne donnons pas faire.

Il s'agit bien de l'usage, article indéfini. Ta position est celle que
j'avais il y a ... (c'est trop loin ;-) ; j'ai évolué.

la copie privée est anecdotique ici, le fond de l'argument qui
prétendrait qu'un code doit se défense / prémunir / etc et qui
justifierait la non existence d'un opérateur de test d'égalité
implicite ne me parait pas fondé.

Le fond de l'argument n'est pas qu'un code doit se prémunir contre
l'existence, mais qu'il doit composer avec -- c'est un contrainte.

c'est ce que je pensais.
Cf msg-ID <q7mje2ls4tlvkbg70l4rfm7utr7giinhrg@4ax.com>
Tu te trompes d'interlocuteur.

je ne me trompe pas, je sais lire les headers, pas de soucis.
mais ce n'est pas de 'Franck B.' en tant que personne dont je
discutais, seulement de l'argument.

Dans ce cas, je reformule :

Il est pour moi une évidence que ce ne doit pas être implicite.

--
Franck Branjonneau

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.

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).

"==" 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 ???

de types qui pourraient exiger du rembourrage,

ton sizeof ne marche pas avec des données paddées ??

pas de type flottant, pas de pointeurs,

ton memcmp ne marche pas sur des octets contenant des float ? ou une
adresse ?

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.

Ç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).

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.

Sylvain.

Sylvain schrieb:

James Kanze wrote on 03/09/2006 14:20:

pas de type flottant, pas de pointeurs,
ton memcmp ne marche pas sur des octets contenant des float ? ou une

adresse ?

Le programme suivant
#include <ostream>
#include <iostream>
#include <limits>
#include <cstring>

int main()
{
double x = std::numeric_limits<double>::quiet_NaN();
std::cout << std::boolalpha
<< x
<< ' '
<< (x == x)
<< ' '
<< (std::memcmp(&x, &x, sizeof x) == 0)
<< 'n';
return 0;
}

affiche chez moi
nan false true

Falk

Falk Tannhäuser wrote on 03/09/2006 16:58:

Sylvain schrieb:

James Kanze wrote on 03/09/2006 14:20:

pas de type flottant, pas de pointeurs,
ton memcmp ne marche pas sur des octets contenant des float ? ou une

adresse ?

Le programme suivant
#include <ostream>
#include <iostream>
#include <limits>
#include <cstring>

int main()
{
double x = std::numeric_limits<double>::quiet_NaN();
std::cout << std::boolalpha
<< x
<< ' '
<< (x == x)
<< ' '
<< (std::memcmp(&x, &x, sizeof x) == 0)
<< 'n';
return 0;
}

affiche chez moi
nan false true

donc memcmp fonctionne très bien sur un double,
merci pour cette confirmation.

Sylvain.

Sylvain schrieb:

donc memcmp fonctionne très bien sur un double,
merci pour cette confirmation.

... et l'opérateur== ne fonctionnerait pas bien,
puisqu'il ne donne pas le même résultat que memcmp ?

Falk

Sylvain <noSpam@mail.net> écrivait:

Franck Branjonneau wrote on 03/09/2006 16:01:

je l'introduisais de fait comme une comparaison du type de structure
et bit-à-bit de son contenu.

Celle que tu proposes correspond à son acception première. Mais par qui ?
Và dire à un physicien que 5 m n'est pas égal à 50 dm ; oui le
mathématicien à décidé de représenter les longueurs comme
des couples (valeur, unité) et (5, m) diffère bien de (50, dm).

oui et ? même les physiciens utilisent le SI s'ils veulent "comparer"
leurs résultats / données.

Ce qu'ils compare c'est des longueurs, ce que tu proposes c'est de
faire ses comparaisons sur la représentation de ses longueurs. Je suis
plus souvent amené à comparer des longueurs que leur représentation ;
ta proposition quelle que soit sa pertinence/valeur/... m'est
inutile. Là où je dis non c'est quand tu proposes d'en faire un
défaut, parce qu'alors en plus de ne me servir à rien il va falloir
que je compose avec : c'est une contrainte.

mais 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à?

Pour autant que je sache, elle n'en parle pas beaucoup sans toutefois
les ignorer (ce sont des détails d'implémentation).

--
Franck Branjonneau

Sylvain <noSpam@mail.net> écrivait:

Franck Branjonneau wrote on 03/09/2006 16:01:

je l'introduisais de fait comme une comparaison du type de structure
et bit-à-bit de son contenu.

Celle que tu proposes correspond à son acception première. Mais par qui ?
Và dire à un physicien que 5 m n'est pas égal à 50 dm ; oui le
mathématicien à décidé de représenter les longueurs comme
des couples (valeur, unité) et (5, m) diffère bien de (50, dm).

oui et ? même les physiciens utilisent le SI s'ils veulent "comparer"
leurs résultats / données.

Ce qu'ils comparent c'est des longueurs, ce que tu proposes c'est de
faire ces comparaisons sur la représentation de ses longueurs. Je suis
plus souvent amené à comparer des longueurs que leur représentation ;
ta proposition quelle que soit sa pertinence/valeur/... m'est
inutile. Là où je dis non c'est quand tu proposes d'en faire un
défaut, parce qu'alors en plus de ne me servir à rien il va falloir
que je compose avec : c'est une contrainte.

mais 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à?

Pour autant que je sache, elle n'en parle pas beaucoup sans toutefois
les ignorer (ce sont des détails d'implémentation).

--
Franck Branjonneau

Sylvain <noSpam@mail.net> écrivait:

Franck Branjonneau wrote on 03/09/2006 16:01:

"un" usage à montré ... 'ma' pratique me montre ...

Il s'agit bien de l'usage, article indéfini. Ta position est celle que
j'avais il y a ... (c'est trop loin ;-) ; j'ai évolué.

c-a-d ? tu es une personne "évoluée" donc ayant toujours raison tandis
que ceux faisant ce que tu as fait jadis sont des arriérés ?

Si c'est l'impression que je t'ai donné, j'en suis désolé. Bien que
j'ai toutes les raisons de comprendre ton choix, je le crois marginal
(ce n'est pas un jugement de valeur)(je n'ai aucune étude pour étayer
ma remarque, elle est biaisée).

--
Franck Branjonneau

Sylvain wrote:

pour reprendre ta function template précédente, devoir définir un

template< typename L, typename R >
bool operator==(const L& left, const R& right)
{
return typeid(left) == typeid(right)
&& memcmp(&left, &right, sizeof(L)) == 0;
}

m'irait très bien, mais 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.

N'oublie pas non plus que rien ne garantit que l'adresse de la
vtable soit identique dans les deux objets, même s'ils ont le
même type, qu'il existe des -0.0 sur prèsque toutes les
plate-formes, qui doit comparer égal à +0.0, même en aillant une
autre représentation, et que sur certaines architectures, deux
pointeurs peuvent avoir des représentations différentes, tout en
désignant la même adresse memoire (et donc le même objet).

--
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