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