Pas d'operateur de comparaison par defaut

Sylvain wrote:

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.

Un NaN n'est JAMAIS égal à quoi que ce soit, y compris à lui-même.
Autrement dit, dans ce cas, memcmp se trompe...

Arnaud

Le 06-09-2006, Sylvain <noSpam@mail.net> a écrit :

Olivier Croquette wrote on 06/09/2006 08:25:

Sylvain wrote:

je ne suis pas tout à fait d'accord avec cette "vision": le compilo ne
connait, ni ne "voit", tous les membres consciemment.

Dans le cas d'une classe, comme expliques-tu alors la recopie
membre-à-membre (avec appel aux opérateurs de recopie de ses attributs
par défauts OU redéfinis) que le compilo met en place?

si un opérateu r de copie existe (est défini par l'auteur) il est
utilisé, sinon c'est un memcpy !! ni plus, ni moins.

btw, c'est ce qui n'explique pas - à mes yeux - les réactions envers un
(mauvais) opérateur implicite basé sur memcmp; l' "intelligence" de
l'opération serait semblable.

Hormis: le padding et le cas du NaN.
Donc, il serait pire.

on peut avancer que le premier est mauvais est qu'en rajouter du même
tonneau serait diabolique, on peut aussi en profiter pour revisiter
(autant que faire ce peut) ces 2 aspects.

Compatibilité avec le C...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)

Olivier Croquette <ocroquette@ocroquette.free.fr> écrivait:

Mais en ce qui me concerne, le problème n'est pas tant d'avoir un
opérateur *implicite* de comparaison membre à membre, mais d'en avoir
un tout court.

Si tu es prêt à en payer le prix :

#include <ios>
#include <iostream>

#include <boost/tuple/tuple.hpp>
#include <boost/tuple/tuple_comparison.hpp>


struct S:
boost::tuple< int, double > {

typedef boost::tuple< int, double > Base;

S(
int i,
double d):
Base(boost::make_tuple(i, d)) {

}

};



int
main() {

S const c(1, 1.0);
S v(1, 1.0);

std::cout << std::boolalpha << (c == v) << "n";

v.get< 1 >()= 0;
std::cout << std::boolalpha << (c == v) << "n";

}

--
Franck Branjonneau

Marc Boyer wrote on 06/09/2006 14:24:

btw, c'est ce qui n'explique pas - à mes yeux - les réactions envers un
(mauvais) opérateur implicite basé sur memcmp; l' "intelligence" de
l'opération serait semblable.

Hormis: le padding et le cas du NaN.
Donc, il serait pire.

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

ensuite que la copie utilise des registres de taille identique aux
argument ou des multiples (32 ou 64 bits) égaux à l'alignement, elle
n'empêchera pas une comparaison bit à bit.

- NaN n'est pas une valeur, donc rappeler que NaN n'est pas unique était
une porte ouverte; par contre ayant un entier évalué comme NaN (par
_isnan) sa copie par memcmp sera également évaluée comme NaN.


Sylvain.

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

?

-- Gaby

Sylvain <noSpam@mail.net> writes:

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

qui est ?

-- Gaby

Olivier Croquette <ocroquette@ocroquette.free.fr> writes:

[...]

| Mais en ce qui me concerne, le problème n'est pas tant d'avoir un
| opérateur *implicite* de comparaison membre à membre, mais d'en avoir
| un tout court.

En effet.

Nous avons pensé au problème en long, en large, et en travers. Il y a
puet-être une solution, mais il faudra attendre 2010 ou plus.

-- Gaby

Sylvain <noSpam@mail.net> writes:

| Olivier Croquette wrote on 04/09/2006 22:47:
| > Bref, il n'y a pas d'opérateur de comparaison membre à membre
| > valable dans la plupart des applications courantes.
| >
| votre énoncé est contradictoire!
|
| une solution "valable pour la plupart des cas" impose un traitement
| générique (comme un memcmp sur la taille de la struct).

?

-- Gaby

Sylvain <noSpam@mail.net> writes:

| Olivier Croquette wrote on 05/09/2006 20:14:
| >>
| >> une comparaison membre-à-membre est nécessairement un opérateur
| >> défini par l'auteur (et même une macro de l'éditeur suppose une
| >> action du codeur).
| > Non, non et non, justement.
| > Le compilateur connait les membres automatiquement, et pourrait
| > mettre à disposition un opérateur de comparaison membre à membre,
| > tout comme il le fait déjà pour l'opérateur de recopie.
|
| je ne suis pas tout à fait d'accord avec cette "vision": le compilo ne
| connait, ni ne "voit", tous les membres consciemment.

ah bon ? C'est lr principe de Sylvain ?

-- Gaby

Sylvain <noSpam@mail.net> writes:

| Marc Boyer wrote on 06/09/2006 14:24:
| >>
| >> btw, c'est ce qui n'explique pas - à mes yeux - les réactions
| >> envers un (mauvais) opérateur implicite basé sur memcmp; l'
| >> "intelligence" de l'opération serait semblable.
| > Hormis: le padding et le cas du NaN.
| > Donc, il serait pire.
|
| - 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.

Pourquoi ?

-- Gaby