VC 14 est idiot ou c'est moi ??

dans une classe Integer, j'ai:

void operator= (long);
void operator= (const Integer&);
void operator= (const Bytes&);
void operator= (const char*);

où "Bytes" est une classe définissant un byte-array.

pour des déclarations telles:

Integer a; // membre d'une classe

const Integer* n = ....... // expression déduite
a = *n; // ERROR

ou encore

Integer m = ..... // expression calculée
a = m; // ERROR

sur les 2 affect. de 'a' le compilo sort une erreur "operateur ambigu"
ne savant pas choisir entre =(const Integer&) et =(const Bytes&).
(pourquoi pas les 2 autres ?...)

la classe Integer ne défini aucun operateur de cast implicite vers Bytes

j'ai du mal à saisir ce qui l'empêche de voir qu'un Integer const est
un Integer const ! y'a une logique ... ou un bug ?
(VC 12 compilait très bien ces expressions).

Sylvain.

On Sun, 11 May 2008 02:41:37 +0200, "Sylvain SF"
<sylvain@boiteaspam.info>:

>dans une classe Integer, j'ai:
>
> void operator= (long);

Il y a là un truc bizarre : normalement, un X:perator= devrait
renvoyer un "X&" :

X& X:perator= (...)
{
...
return *this;
}

> void operator= (const Integer&);
> void operator= (const Bytes&);
> void operator= (const char*);
>
>où "Bytes" est une classe définissant un byte-array.
>
>pour des déclarations telles:
>
>Integer a; // membre d'une classe
>
>const Integer* n = ....... // expression déduite
>a = *n; // ERROR

Il faudrait donner un code minimaliste qui exhibe l'erreur. Ce
faisant, il y a d'ailleurs de bonnes chances que tu découvres le
problème toi-même.

Je suis prêt à parier qu'aucun compilateur n'a jamais indiqué d'erreur
dans le code suivant :


class Bytes {};

class Integer
{
public:
Integer& operator= (long);
Integer& operator= (const Integer&);
Integer& operator= (const Bytes&);
Integer& operator= (const char*);
};

int main()
{
Integer a;
const Integer* n= new Integer;
a = *n;
}

Fabien LE LEZ wrote on 11/05/2008 02:57:
>
> Il y a là un truc bizarre : normalement, un X:perator= devrait
> renvoyer un "X&" :

"pourrait" -- ici je préfère qu'il ne retourne rien.

> Il faudrait donner un code minimaliste qui exhibe l'erreur. Ce
> faisant, il y a d'ailleurs de bonnes chances que tu découvres le
> problème toi-même.

le code était celui-là: "a = *n;" ... sauf que n est un ASN1Integer
et non un Integer, or ASN1Integer définissait (où 'n' est un Integer
membre):

operator Bytes () const { return n.getBytes(); }
operator const Integer& () const { return n; }

le 1ier cast est inélégant et source des pbs.

on ne relit jamais assez (et l'output de VC 14 est merdique à lire).

Sylvain.

On Sun, 11 May 2008 03:17:17 +0200, "Sylvain SF" :

>> Il y a là un truc bizarre : normalement, un X:perator= devrait
>> renvoyer un "X&" :
>
>"pourrait" -- ici je préfère qu'il ne retourne rien.

Auquel cas il y a, à côté, un commentaire indiquant pourquoi -- ça
évite au lecteur de passer trop de temps à buter contre cette
bizarrerie.

>> Il faudrait donner un code minimaliste qui exhibe l'erreur. Ce
>> faisant, il y a d'ailleurs de bonnes chances que tu découvres le
>> problème toi-même.
>
>le code était celui-là: "a = *n;"

Je parlais d'un code compilable.
Si tu écris

a = *n;

dans un fichier .cpp, ça ne compilera pas.

Fabien LE LEZ wrote on 11/05/2008 03:36:
> On Sun, 11 May 2008 03:17:17 +0200, "Sylvain SF" :
>
>>> Il y a là un truc bizarre : normalement, un X:perator= devrait
>>> renvoyer un "X&" :
>> "pourrait" -- ici je préfère qu'il ne retourne rien.
>
> Auquel cas il y a, à côté, un commentaire indiquant pourquoi -- ça
> évite au lecteur de passer trop de temps à buter contre cette
> bizarrerie.

ce n'était pas le point !...

si Integer& operator= (const Integer&) était défini, alors le lecteur
risquerait de buter sur des (a, b, c, d étant des Integer):

a = b = c + d;
a = (b = c) + d;

je ne veux pas de ces écritures, ni des "(a = b).foo();",
d'ou le choix.

Sylvain.

On Sun, 11 May 2008 03:47:07 +0200, "Sylvain SF" :

> a = b = c + d;
> a = (b = c) + d;
>
>je ne veux pas de ces écritures

Si a et b sont des int, l'écriture "a=b=3" est parfaitement valide, et
même assez commune.
Ce qui signifie que :
- Tu n'empêcheras pas cette écriture, puisqu'on peut l'utiliser
avec d'autres types. Et de toute façon, quelqu'un qui veut écrire un
code illisible, y arrivera sans peine.
- Du code valide avec int, ne l'est plus avec Integer. La classe
"Integer" est donc d'un maniement fondamentalement différent de int,
et son nom risque d'induire l'utilisateur en erreur.

In article <48265018$0$928$ba4acef3@news.orange.fr>,
Sylvain SF <sylvain@boiteaspam.info> wrote:
>si Integer& operator= (const Integer&) était défini, alors le lecteur
>risquerait de buter sur des (a, b, c, d étant des Integer):
>
> a = b = c + d;
> a = (b = c) + d;
>
>je ne veux pas de ces écritures, ni des "(a = b).foo();",
>d'ou le choix.

Mais c'est une deviation par rapport aux usages courants, qui disent
tres clairement: "la surcharge d'operateur, c'est suffisamment complique
comme ca, alors par pitie, respectez toujours la signature des operateurs
par defaut".

Donc a partir du moment ou ton code est publie(*), il *faut* le
documenter.

* note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.

On 11 mai, 11:58, es...@lain.home (Marc Espie) wrote:
> In article <48265018$0$928$ba4ac...@news.orange.fr>,
> Sylvain SF <sylv...@boiteaspam.info> wrote:

[...]
> Donc a partir du moment ou ton code est publie(*), il *faut*
> le documenter.

> * note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.

Je ne suis pas tout à fait d'accord. Il y a publication, et
publication, et quand je poste quelque chose dans le news, en
général, c'est pour éclaircir ou démander sur un point précis.
Du coup, je me permets beaucoup de simplifications que je ne me
permettrais jamais dans du code réel. Dans ce cas-ci, je ne suis
pas d'accord avec Sylvain ; à mon avis, dans le C++, l'opérateur
d'affectation est un lvalue, et si pour une raison quelconque,
il ne faut pas qu'il renvoie une référence à l'objet, c'est une
signe que l'utilisation de l'opérateur (plutôt qu'une fonction
membre) est un abus du surcharge. (Mais Sylvain n'est
certainement pas le seul à se donner à ce genre de surcharge. Je
connais une bibliothèque C++ avec des classes qui supportent
certaines opérations sur des pointeurs, genre * et ->, mais qui
ne supportent pas la comparaison avec NULL.) Seulement, le
problème n'est pas la publication ici.

Aussi, à mon avis, tout code est pour « publication », c-à-d
conçu pour être lu par les autres. Même si le cercle des
lecteurs est assez restreint (disons les programmeurs qui
participent dans la revue, plus un ou deux programmeurs de
maintenance dans la même boîte).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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

Marc Espie wrote on 11/05/2008 11:58:
>
> Donc a partir du moment ou ton code est publie(*), il *faut* le
> documenter.
> * note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.

tu me demanderais alors de raconter ma vie sur un point qui:
- n'est pas la source du problème,
- n'a rien à voir avec la question posée.

ce type de documentation ne me parait pas indispensable ici.

pour ces besoins, une classe comme un Integer ne me parait pas
en tout point comparable à un POD quelconque, qu'il fasse des
entorses aux usages courants n'est pas un grand problème.
de fait 95% des operations (publiques) sur une telle classe
sont justement des opérateurs surchargés ou introduits,
l'utilisateur devra donc lire leurs définitions, celle du =
comme par exemple celle du post-incrément qui est également
void pour éviter le cout d'une copie.

Sylvain.

On Sun, 11 May 2008 17:23:03 +0200, "Sylvain SF" :

>tu me demanderais alors de raconter ma vie sur un point qui:
>[...]

....est surtout *la* grosse bizarrerie du code que tu as posté ici. On
ne peut pas voir un tel code sans se poser des questions.

>pour ces besoins, une classe comme un Integer ne me parait pas
>en tout point comparable à un POD quelconque, qu'il fasse des
>entorses aux usages courants n'est pas un grand problème.

Tant que tu es la seule victime de ces bizarreries, en effet, ce n'est
pas gênant pour les autres.

>de fait 95% des operations (publiques) sur une telle classe
>sont justement des opérateurs surchargés ou introduits,
>l'utilisateur devra donc lire leurs définitions,

Et les avoir en tête en permanence.
Sans oublier l'impossibilité d'utiliser du code générique (templates),
puisque l'interface est fondamentalement différente de toutes les
autres interfaces.

>comme par exemple celle du post-incrément qui est également
>void pour éviter le cout d'une copie.

Uh ? Pour le coup, je comprends de moins en moins. Quand on utilise le
"post-incrément", c'est justement parce qu'on a besoin d'une copie de
la valeur précédente. Sinon on utilise le "pré-incrément".

Fabien LE LEZ wrote on 11/05/2008 17:54:
> On Sun, 11 May 2008 17:23:03 +0200, "Sylvain SF" :
>
>> tu me demanderais alors de raconter ma vie sur un point qui:
>> [...]
>
> ....est surtout *la* grosse bizarrerie du code que tu as posté ici. On
> ne peut pas voir un tel code sans se poser des questions.

oui ?!? il fait trop chaud ? on s'ennuie avec tous ces viaducs oisifs ?

> Tant que tu es la seule victime de ces bizarreries, en effet, ce n'est
> pas gênant pour les autres.

hmm, je ne suis que victime d'avoir mal lu mon code à 4h du mat...

> Sans oublier l'impossibilité d'utiliser du code générique (templates)

tu sais bien que j'en utilise aucun.
(et traiter génériquement void ou X& ne gènerait en rien la généricité).

> Quand on utilise le "post-incrément", c'est justement parce qu'on
> a besoin d'une copie de la valeur précédente.

ou pas - compte le nb de tes boucles "for (, , i++)" pour voir.

Sylvain.

"Sylvain SF" <sylvain@boiteaspam.info> writes:

| Marc Espie wrote on 11/05/2008 11:58:
| >
| > Donc a partir du moment ou ton code est publie(*), il *faut* le
| > documenter.
| > * note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.
|
| tu me demanderais alors de raconter ma vie sur un point qui:

Et pourtant tu le fais tout le temps, ici et ailleurs.

-- Gaby

In article <48270f57$0$897$ba4acef3@news.orange.fr>,
Sylvain SF <sylvain@boiteaspam.info> wrote:
>Marc Espie wrote on 11/05/2008 11:58:
>>
>> Donc a partir du moment ou ton code est publie(*), il *faut* le
>> documenter.
>> * note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.
>
>tu me demanderais alors de raconter ma vie sur un point qui:
>- n'est pas la source du problème,
>- n'a rien à voir avec la question posée.
>
>ce type de documentation ne me parait pas indispensable ici.

Dans mon boulot, j'essaie d'enseigner a des gens comment programmer
proprement, en particulier, comment eviter un serieux paquet de trous
de securite et de bugs divers et varies.

Un des concepts fondateurs que j'essaie de leur inculquer, c'est de
faire le plus simple possible, en particulier de suivre les regles
sauf raison extremement motivee.

Un deuxieme concept, c'est qu'un code evolue, est lu et modifie par
plusieurs personnes en general, et qu'une bonne dose des problemes
sont directement lies a des erreurs de communication entre personnes.

>l'utilisateur devra donc lire leurs définitions, celle du =
>comme par exemple celle du post-incrément qui est également
>void pour éviter le cout d'une copie.

.... et s'en souvenir. Autant de details inutiles en tete qui occupent une
place precieuse, qui serait plus avantageusement prise par des choses
utiles.


La conclusion de ce que je raconte, c'est que 95% de ce qu'on ecrit
comme programmes sont des choses banales sans interet, qu'il convient
d'ecrire le plus simplement ET le plus rapidement possible, sans astuces
particulieres ni idiosyncrasies personnelles, histoire de pouvoir
reellement se concentrer sur les 5% qui restent.

Tu me suis mieux ?

Marc Espie wrote on 11/05/2008 20:47:
>
> Tu me suis mieux ?

non, je n'ai aucune raison de te suivre sur ce chemin.
évidemment cela ne s'oppose nullement aux évidences que tu énonces.

Sylvain.

Gabriel Dos Reis wrote on 11/05/2008 19:59:
> "Sylvain SF" <sylvain@boiteaspam.info> writes:
>
> | Marc Espie wrote on 11/05/2008 11:58:
> | >
> | > Donc a partir du moment ou ton code est publie(*), il *faut* le
> | > documenter.
> | > * note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.
> |
> | tu me demanderais alors de raconter ma vie sur un point qui:
>
> Et pourtant tu le fais tout le temps, ici et ailleurs.

"Ce groupe est dédié aux discussions autour du langage C++ uniquement".

<http://www.faqs.org/faqs/fr/chartes/comp.lang.cpp/>

Sylvain.

"Sylvain SF" <sylvain@boiteaspam.info> writes:

| Gabriel Dos Reis wrote on 11/05/2008 19:59:
| > "Sylvain SF" <sylvain@boiteaspam.info> writes:
| >
| > | Marc Espie wrote on 11/05/2008 11:58:
| > | >
| > | > Donc a partir du moment ou ton code est publie(*), il *faut* le
| > | > documenter.
| > | > * note qu'en demandant de l'aide ici, c'est exactement ce que tu fais.
| > |
| > | tu me demanderais alors de raconter ma vie sur un point qui:
| >
| > Et pourtant tu le fais tout le temps, ici et ailleurs.
|
| "Ce groupe est dédié aux discussions autour du langage C++ uniquement".

Tu t'en rappelles lorsque tu n'as plus rien à raconter.

Bonne chance.

-- Gaby

Gabriel Dos Reis wrote on 12/05/2008 12:15:
> "Sylvain SF" <sylvain@boiteaspam.info> writes:
>
> | Gabriel Dos Reis wrote on 11/05/2008 19:59:
> | > "Sylvain SF" <sylvain@boiteaspam.info> writes:
> | >
> | > | tu me demanderais alors de raconter ma vie sur un point qui:
> | >
> | > Et pourtant tu le fais tout le temps, ici et ailleurs.
> |
> | "Ce groupe est dédié aux discussions autour du langage C++ uniquement".
>
> Tu t'en rappelles lorsque tu n'as plus rien à raconter.

mais t'as vraiment rien d'autre à foutre mon pauvre gabriel ???

un expert comme toi, même peut être un adulte, jouer à touche-pipi
ou à mesurer des bites en guettant mes posts pour y verser ta petite
vanne, c'est vraiment pathétique.

je te rappelles que je suis une sous-merde, il y a déjà 20 ans,
j'étais traité d'idiot par un X dont je corrigeais les boucles
mal codées en Fortran ou d'affabulateur par un normalien dont
j'accélerais de 20% le code ("X operator# (const X&, const X&)"
à la place de "operator# (X, X)", # in {+,-,*,/,%, etc}), alors
tes vannes nulles d'"ici ou ailleurs" (puisque gaby est partout)
tu imagines bien que je suis trop médiocre pour les apprécier -
et s'il te plait arrêtes donc de te rabaisser en voulant montrer
que tu es plus précis, plus fin, plus pertinent qu'un pauvre tétard,
en un mot OUBLIE-MOI.

Sylvain.

"Sylvain SF" <sylvain@boiteaspam.info> writes:

| Gabriel Dos Reis wrote on 12/05/2008 12:15:
| > "Sylvain SF" <sylvain@boiteaspam.info> writes:
| >
| > | Gabriel Dos Reis wrote on 11/05/2008 19:59:
| > | > "Sylvain SF" <sylvain@boiteaspam.info> writes:
| > | >
| > | > | tu me demanderais alors de raconter ma vie sur un point qui:
| > | >
| > | > Et pourtant tu le fais tout le temps, ici et ailleurs.

[...]

| je te rappelles que je suis une sous-merde, il y a déjà 20 ans,

CQFD.

-- Gaby

Gabriel Dos Reis wrote on 12/05/2008 18:32:
> "Sylvain SF" <sylvain@boiteaspam.info> writes:
>
> | Gabriel Dos Reis wrote on 12/05/2008 12:15: | > "Sylvain SF"
> <sylvain@boiteaspam.info> writes: | > | > | Gabriel Dos Reis wrote on
> 11/05/2008 19:59: | > | > "Sylvain SF" <sylvain@boiteaspam.info>
> writes: | > | > | > | > | tu me demanderais alors de raconter ma vie
> sur un point qui: | > | > | > | > Et pourtant tu le fais tout le
> temps, ici et ailleurs.
>
>> mais t'as vraiment *rien* *d'autre* *à* *foutre* mon pauvre gabriel ???
>
> CQFD.

pareil.

On 11 mai, 02:41, "Sylvain SF" <sylv...@boiteaspam.info> wrote:
> VC 14 est idiot ou c'est moi ??
>
> dans une classe Integer, j'ai:
>
> void operator= (long);
> void operator= (const Integer&);
> void operator= (const Bytes&);
> void operator= (const char*);
>
> où "Bytes" est une classe définissant un byte-array.
>
> pour des déclarations telles:
>
> Integer a; // membre d'une classe
>
> const Integer* n = ....... // expression déduite
> a = *n; // ERROR
>
> ou encore
>
> Integer m = ..... // expression calculée
> a = m; // ERROR
>
> sur les 2 affect. de 'a' le compilo sort une erreur "operateur ambigu"
> ne savant pas choisir entre =(const Integer&) et =(const Bytes&).
> (pourquoi pas les 2 autres ?...)
>
> la classe Integer ne défini aucun operateur de cast implicite vers Bytes
>
> j'ai du mal à saisir ce qui l'empêche de voir qu'un Integer const est
> un Integer const ! y'a une logique ... ou un bug ?
> (VC 12 compilait très bien ces expressions).
>
> Sylvain.

Ta classe integer n'aurait-elle pas un opérateur de cast ?

Sté.

digR a écrit :
> On 11 mai, 02:41, "Sylvain SF" <sylv...@boiteaspam.info> wrote:
>> la classe Integer ne défini aucun operateur de cast implicite vers Bytes
> Ta classe integer n'aurait-elle pas un opérateur de cast ?

Apparemment non.

>> (VC 12 compilait très bien ces expressions).

C'est ça qui est bizarre.
Est ce que tu compilais exactement le même source ?

Michael

digR wrote on 13/05/2008 16:05:
>>
>> dans une classe Integer, [...]
>
> Ta classe integer n'aurait-elle pas un opérateur de cast ?

le fil n'est pas spontanément facile à lire; le problème était réglé
avec mon second post (11/05 @ 03:17); les 16 posts suivants sont du
bruit sans aucun intérêt - des admirateurs qui s'emmerdent ...

la classe Integer n'a pas de cast vers Bytes, mais l'affectation en
erreur n'impliquait pas un Integer mais un ASN1Integer (erreur de
lecture de mon code) qui lui possédait un cast fautif.

en effet Michael, le source avait changé depuis la compil. par cl.12
avec cet operator utilisé pour un test ou immédiatement oublié.

Sylvain.