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).
On Sun, 11 May 2008 03:17:17 +0200, "Sylvain SF" :
Il y a là un truc bizarre : normalement, un X::operator= 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.
Fabien LE LEZ
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.
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.
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.
espie
In article <48265018$0$928$, Sylvain SF 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.
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.
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.
James Kanze
On 11 mai, 11:58, (Marc Espie) wrote:
In article <48265018$0$928$, Sylvain SF 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: 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
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
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: 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
Sylvain SF
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.
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.
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.
Fabien LE LEZ
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".
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".
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".
Sylvain SF
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.
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.
