 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Dimitri PAPADOPOULOS-ORFA
Guest
|
 Posted: Wed May 11, 2005 3:45 pm Post subject: enums anonymes |
 |
|
Bonjour,
Quelqu'un aurait-il l'amabilité de m'expliquer pourquoi le code suivant
serait invalide ? Messages d'erreur incompréhensibles gracieusement
fournis par gcc 4.0.0...
$ cat foo.cc
class MyClass {
};
template <typename T>
void
operator<<(MyClass& b, const T& t) {
}
enum { HSize };
int main() {
int i;
i<
}
$
$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:13: error: '
foo.cc:13: error: trying to instantiate 'template<class T> void
operator<<(MyClass&, const T&)'
$
--
Dimitri Papadopoulos
|
|
| Back to top |
|
 |
kanze@gabi-soft.fr
Guest
|
| Posted: Wed May 11, 2005 5:06 pm Post subject: Re: enums anonymes |
|
|
Dimitri PAPADOPOULOS-ORFANOS wrote:
| Quote: | Quelqu'un aurait-il l'amabilité de m'expliquer pourquoi le
code suivant serait invalide ? Messages d'erreur
incompréhensibles gracieusement fournis par gcc 4.0.0...
$ cat foo.cc
class MyClass {
};
template <typename T
void
operator<<(MyClass& b, const T& t) {
}
enum { HSize };
int main() {
int i;
i<
}
$
$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:13: error: '
foo.cc:13: error: trying to instantiate 'template<class T> void
operator<<(MyClass&, const T&)'
$
|
Le message ne me semble pas si mauvais que ça. Il dit exactement
ce que tu fais de faux : tu utilise un type anonyme en essayant
d'initialiser un template. Alors que c'est dit très
explicitement dans la norme que des types sans nom ne peuvent
pas servir ici. (J'avoue que pour une fois, la norme ne m'a pas
surpris en ce qui concerne les templates. Dans la mésure où la
norme exige en général que le type d'instantiation soit
globalement visible, je vois mal comment il permettrait des
instantiations sur des types anonyme.)
--
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
|
|
| Back to top |
|
|
AG
Guest
|
| Posted: Thu May 12, 2005 10:28 am Post subject: [HS] |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | surpris en ce qui concerne les templates. Dans la mésure où la
Bonjour Monsieur, |
Je me permet une petite remarque :
"Dans la mesure" au lieu de "Dans la mésure".
Comme personne n'ose/ne juge nécessaire de vous reprendre, et que vous
la faite souvent (ça n'a pas l'air d'être un oubli), et que vu votre
niveau de français, vous avez largement la capacité de l'intégrer, je me
suis permis cette petite remarque, en toute humilité.
Cordialement,
AG.
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu May 12, 2005 11:28 am Post subject: Re: [HS] |
|
|
AG wrote:
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote:
surpris en ce qui concerne les templates. Dans la mésure où la
Je me permet une petite remarque :
"Dans la mesure" au lieu de "Dans la mésure".
Comme personne n'ose/ne juge nécessaire de vous reprendre, et
que vous la faite souvent (ça n'a pas l'air d'être un oubli),
et que vu votre niveau de français, vous avez largement la
capacité de l'intégrer, je me suis permis cette petite
remarque, en toute humilité.
|
Et je vous en remercie -- ce n'est qu'à travers de telles
remarques qu'on progresse, et c'est une fausse politesse de ne
pas les faire. (Normalement, on les fait par email, mais puisque
je n'affiche pas d'adresse email valable, mieux vaut ici que pas
du tout.)
En passant, je remarque qu'il y a effectivement deux choses que
ma tête refuse à retenir : les accents et les genres. Tous les
deux absents, évidemment, de ma langue d'origine. (Heureusement
qu'il n'y a ni l'un ni l'autre en C++.)
--
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
|
|
| Back to top |
|
|
Dimitri PAPADOPOULOS-ORFA
Guest
|
| Posted: Fri May 13, 2005 3:28 pm Post subject: Re: enums anonymes |
|
|
Bonjour,
| Quote: | Le message ne me semble pas si mauvais que ça. Il dit exactement
ce que tu fais de faux : tu utilise un type anonyme en essayant
d'initialiser un template. Alors que c'est dit très
|
En fait ce que le code en question essaie de faire, c'est d'appliquer
l'opérateur de décalage << à un entier "i".
Or le compilateur n'accepte pas d'enum à droite de l'opérateur << de
décalage, ce qu'il acceptait jusqu'à présent :
i<
Il veut absolument un int :
i<
Du coup le compilateur va chercher un opérateur << ailleurs. Pour moi la
raison première pour laquelle cet opérateur ne peut s'appliquer n'est
pas une sombre histoire d'enum anonyme. C'est tout simplement que le
premier argument devrait être de type "MyClass" or l'argument "i" est un
int. Manifestement le compilateur bute sur le deuxième argument "HSize"
avant de buter sur le premier argument "i" ce qui serait naturel pour un
humain.
Le problème du message d'erreur c'est qu'il faut comprendre le
cheminement du compilateur avant de comprendre le message. Il y a deux
problèmes ici :
1) L'opérateur de décalage << n'accepte pas d'enum à la place d'un int
comme deuxième argument. Je suis d'accord qu'il n'y a pas encore erreur
à ce niveau, done le compilateur ne génère pas de message d'erreur pour
le moment.
2) Le compilateur cherche alors un opérateur << qui s'applique dans ce
cas. Le seul template qu'il trouve ne s'applique pas dans ce cas, de
façon évident si on regarde le premier argument et pour des raisons
obscures en ce qui concerne le deuxième argument. Or le compilateur
génère un message d'erreur pour le deuxième arguent, ce qui est
totalement contre-intuitif.
3) Le compilateur pourrait dans ce cas précis, après avoir constaté que
manifestement aucun template ne s'applique dans ce cas, revenir au point
1) et dire qu'un enum ne peut être utilisé à la place d'un int.
Au final, le message d'erreur devrait être :
foo.cc:13: error: '
au lieu de :
foo.cc:13: error: '<anonymous enum>' is/uses anonymous type
foo.cc:13: error: trying to instantiate 'template<class T> void
operator<<(MyClass&, const T&)'
| Quote: | explicitement dans la norme que des types sans nom ne peuvent
pas servir ici. (J'avoue que pour une fois, la norme ne m'a pas
surpris en ce qui concerne les templates. Dans la mésure où la
norme exige en général que le type d'instantiation soit
globalement visible, je vois mal comment il permettrait des
instantiations sur des types anonyme.)
|
Une fois de plus du code qui marchait pendant des années se met tout
d'un coup à ne plus fonctionner... Au moins cette fois-ci c'est moins
grave que d'habitude. Pas étonnant qu'on soit en train d'abandonner C++
pour Python dans mon labo (avec du C++ pour les parties à optimiser
quand même) : les thésards et post-docs même pointus en informatique
perdent leur temps à se battre avec les détails de la norme plutôt que
d'avancer dans leur travail.
--
Dimitri Papadopoulos
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Fri May 13, 2005 6:51 pm Post subject: Re: enums anonymes |
|
|
Dimitri PAPADOPOULOS-ORFANOS <papadopo (AT) shfj (DOT) REMOVE.cea.NOSPAM.fr> writes:
| Quote: | Bonjour,
Le message ne me semble pas si mauvais que ça. Il dit exactement
ce que tu fais de faux : tu utilise un type anonyme en essayant
d'initialiser un template. Alors que c'est dit très
En fait ce que le code en question essaie de faire, c'est d'appliquer
l'opérateur de décalage << à un entier "i".
|
Oui.
| Quote: | Or le compilateur n'accepte pas d'enum à droite de l'opérateur << de
décalage, ce qu'il acceptait jusqu'à présent :
i<
Il veut absolument un int :
i<
Du coup le compilateur va chercher un opérateur << ailleurs. Pour moi
la raison première pour laquelle cet opérateur ne peut s'appliquer
n'est pas une sombre histoire d'enum anonyme. C'est tout simplement
que le premier argument devrait être de type "MyClass" or l'argument
"i" est un int. Manifestement le compilateur bute sur le deuxième
argument "HSize" avant de buter sur le premier argument "i" ce qui
serait naturel pour un humain.
|
C'est exact.
Le fait que ce soit un code invalide est discutable. En fait, il y a
même un Core Issue pour ça.
Mon avis personnel que toute règle qui dit que ce code est invalde,
est simplment bugguée et doit être fixée. Cela n'a pas de sens.
-- Gaby
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Fri May 13, 2005 6:55 pm Post subject: Re: enums anonymes |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
[...]
| Quote: | Alors que c'est dit très
explicitement dans la norme que des types sans nom ne peuvent
pas servir ici.
|
Ah bon. Alors même qu'il y a un Core Issue en discussion pour ça.
| Quote: | (J'avoue que pour une fois, la norme ne m'a pas
surpris en ce qui concerne les templates. Dans la mésure où la
norme exige en général que le type d'instantiation soit
globalement visible, je vois mal comment il permettrait des
instantiations sur des types anonyme.)
|
Il n'y a aucun rapport.
(1) le type en question n'est pas utilisé pour faire des opérations
sur les templates;
(2) et même si l'énumération en question était utilisée pour faire
des opérations sur les templates, la notion de visibilité
concerne les *noms* et pas les types.
-- Gaby
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Fri May 13, 2005 6:56 pm Post subject: Re: enums anonymes |
|
|
Dimitri PAPADOPOULOS-ORFANOS <papadopo (AT) shfj (DOT) DECOY.cea.fr> writes:
| Quote: | Bonjour,
Quelqu'un aurait-il l'amabilité de m'expliquer pourquoi le code
suivant serait invalide ? Messages d'erreur incompréhensibles
gracieusement fournis par gcc 4.0.0...
|
Un excès de zèle de la part du compilateur. Il y a un core issue pour
ça.
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon May 16, 2005 7:03 am Post subject: Re: enums anonymes |
|
|
Gabriel Dos Reis wrote:
| Quote: | kanze (AT) gabi-soft (DOT) fr writes:
[...]
| Alors que c'est dit très
| explicitement dans la norme que des types sans nom ne peuvent
| pas servir ici.
Ah bon. Alors même qu'il y a un Core Issue en discussion pour ça.
|
C'est que je n'avais pas noté que l'opérand de gauche était un
int, et non la classe que voulait le template. J'ai lu trop
rapidement.
Alors, je suis étonné dans l'autre sens -- la conversion d'un
enum en int est bien défini, et dans la description des
opérateurs de décalage, il est même dit explicitement qu'on peut
se servir des enum. Alors, même si je ne suis pas très fort en
ce qui concerne les templates... il me semble que dans l'absense
d'une conversion int -> MyClass, le template ne vient même pas
en considération.
Quel est le core issue ? J'aurais cru que les promotions
intégrales fasse qu'il n'y a aucune différence ici entre l'enum
et un int.
| Quote: | | (J'avoue que pour une fois, la norme ne m'a pas surpris en
| ce qui concerne les templates. Dans la mésure où la norme
| exige en général que le type d'instantiation soit
| globalement visible, je vois mal comment il permettrait des
| instantiations sur des types anonyme.)
Il n'y a aucun rapport.
|
Je le reconnais. J'ai mal lu le code.
| Quote: | (1) le type en question n'est pas utilisé pour faire des
opérations
sur les templates;
(2) et même si l'énumération en question était utilisée pour
faire
des opérations sur les templates, la notion de visibilité
concerne les *noms* et pas les types.
|
En ce qui concerne (2), j'aurais cru que §14.3.1 (« A local
type, at type with no linkage, an UNNAMED TYPE or a type
compounded from any of these types shal not be used as a
template-argument for a template type-parameter. ») rendait le
code illégal. Mais comme j'ai dit, les règles en ce qui concerne
les templates sont trop compliquées pour que j'arrive réelement
à les comprendre.
Mon interprétation, ici, c'est que même si c'est le compilateur
qui a déduit le type, c'est le type qui est l'argument. Et que
le type en question n'a pas de nom. (Mais en pensant -- je
dirais aussi qu'un type comme int* n'a pas de nom. Or que je
suis assez sûr qu'on ne veut pas interdire ça comme paramètre
d'un template. Alors, je n'y comprends rien.)
--
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
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon May 16, 2005 10:00 am Post subject: Re: enums anonymes |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
[...]
| Quote: | (2) et même si l'énumération en question était utilisée pour
faire
des opérations sur les templates, la notion de visibilité
concerne les *noms* et pas les types.
En ce qui concerne (2), j'aurais cru que §14.3.1 (« A local
type, at type with no linkage, an UNNAMED TYPE or a type
compounded from any of these types shal not be used as a
template-argument for a template type-parameter. ») rendait le
code illégal. Mais comme j'ai dit, les règles en ce qui concerne
les templates sont trop compliquées pour que j'arrive réelement
à les comprendre.
|
Le passage que tu cites est vrai, mais au fond ce passage ne resiste
pas vraiment à l'analyse et je l'ai déjà dit dans EWG à Redmond
lorsque quelqu'un a proposé à Oxford (Avril 2003) d'autoriser les
types locaux en tant qu'arguments de template (tous les implémenteurs
à l'époque ont dit « oui », c'est faisable) et qu'à Redmond j'ai
entendu une « réticence » pour des raisons que j'ai oubliées.
J'ai entendu des rumeurs sur le mangling, mais comme je l'ai dejà fait
observé, ce n'est pas parce que quelque chose est local ou n'a pas
de nom qu'on ne peut ps le mangler. Pour le premier cas il suffit de
considérer les variables locales statiques et se rendre compte que
tous les compilateurs corrects les manglent (en ce qui concerne
l'idiome courant d'initialization). Pour le second cas, il suffit de
considérer les « unnamed namespace » et ce qu'ils contiennent.
| Quote: | Mon interprétation, ici, c'est que même si c'est le compilateur
qui a déduit le type, c'est le type qui est l'argument. Et que
le type en question n'a pas de nom. (Mais en pensant -- je
dirais aussi qu'un type comme int* n'a pas de nom. Or que je
suis assez sûr qu'on ne veut pas interdire ça comme paramètre
d'un template. Alors, je n'y comprends rien.)
|
Comme j'ai dit, quelque part quelqu'un a confondu « type » et
« nom » et a créé cette confusion. 
Au debut « linkage » concernait les noms, puis il a été étendu aux
types de fonctions (contrairement à l'avertissement de l'ARM) ; et
maintenant il est impliciement utilisé pour autres choses.
Le problème avec le code est que pour faire la résolution de surcharge
de « << », le compilateur doit considérer les « operator<< » dans la
portée ainsi que ceux qui sont câblés. En particulier, pour celui qui
est template, le compilateur doit déduire les arguments de
templates. Or cette phase (préliminaire) déduit un type non nommé,
alors le compilateur se plaint -- même et surtout si la fonction
correspondante n'est jamais utilisée. Intéressant, n'est-ce pas ?
On pourrait faire une règle disant que c'est invalide uniquement si la
fonction est choisie, mais je soupçonne que cela créerait toujours de
la confusion. Je pense que la solution est de simplement autoriser ces
choses là. La restriction est artificielle.
Ah, en ce qui concerne le core issue en question il n'y a pas encore
de numéro public mais c'est devant le CWG (i.e. reflecteur). Note
aussi l'explication
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#278
de Mike Miller tendrait à supporter la vision qu'on peut mangler une
énumération, même si elle n'a pas de nom :-)
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon May 16, 2005 12:21 pm Post subject: Re: enums anonymes |
|
|
Gabriel Dos Reis wrote:
| Quote: | kanze (AT) gabi-soft (DOT) fr writes:
[...]
| > (2) et même si l'énumération en question était utilisée
| > pour faire des opérations sur les templates, la
| > notion de visibilité concerne les *noms* et pas les
| > types.
| En ce qui concerne (2), j'aurais cru que §14.3.1 (« A local
| type, at type with no linkage, an UNNAMED TYPE or a type
| compounded from any of these types shal not be used as a
| template-argument for a template type-parameter. ») rendait le
| code illégal. Mais comme j'ai dit, les règles en ce qui concerne
| les templates sont trop compliquées pour que j'arrive réelement
| à les comprendre.
Le passage que tu cites est vrai, mais au fond ce passage ne
resiste pas vraiment à l'analyse et je l'ai déjà dit dans EWG
à Redmond lorsque quelqu'un a proposé à Oxford (Avril 2003)
d'autoriser les types locaux en tant qu'arguments de template
(tous les implémenteurs à l'époque ont dit « oui », c'est
faisable) et qu'à Redmond j'ai entendu une « réticence » pour
des raisons que j'ai oubliées.
J'ai entendu des rumeurs sur le mangling, mais comme je l'ai
dejà fait observé, ce n'est pas parce que quelque chose est
local ou n'a pas de nom qu'on ne peut ps le mangler. Pour le
premier cas il suffit de considérer les variables locales
statiques et se rendre compte que tous les compilateurs
corrects les manglent (en ce qui concerne l'idiome courant
d'initialization). Pour le second cas, il suffit de considérer
les « unnamed namespace » et ce qu'ils contiennent.
| Mon interprétation, ici, c'est que même si c'est le
| compilateur qui a déduit le type, c'est le type qui est
| l'argument. Et que le type en question n'a pas de nom. (Mais
| en pensant -- je dirais aussi qu'un type comme int* n'a pas
| de nom. Or que je suis assez sûr qu'on ne veut pas interdire
| ça comme paramètre d'un template. Alors, je n'y comprends
| rien.)
Comme j'ai dit, quelque part quelqu'un a confondu « type » et
« nom » et a créé cette confusion. Au debut « linkage »
concernait les noms, puis il a été étendu aux types de
fonctions (contrairement à l'avertissement de l'ARM) ; et
maintenant il est impliciement utilisé pour autres choses.
|
En effet, je crois que tu as mis ton doigt sur le problème. Un
template dépend des types, non des « noms ». Seulement, comme tu
dis, ailleurs dans la norme, les types n'ont pas de linkage. Et
plus généralement, si on a déjà un type, que importe son nom.
(Ou ses noms -- grace aux typedef's, un type peut avoir
plusieurs noms aussi -- dont certains sans linkage, et d'autres
avec.)
| Quote: | Le problème avec le code est que pour faire la résolution de
surcharge de « << », le compilateur doit considérer les «
operator<< » dans la portée ainsi que ceux qui sont câblés. En
particulier, pour celui qui est template, le compilateur doit
déduire les arguments de templates. Or cette phase
(préliminaire) déduit un type non nommé, alors le compilateur
se plaint -- même et surtout si la fonction correspondante
n'est jamais utilisée. Intéressant, n'est-ce pas ?
|
Mais il me semble qu'il y avait quelque part une règle qui
disait que l'impossibilité de pouvoir deduire un template n'est
pas une erreur -- on écarte le template de l'ensemble de
surcharge, et on continue. Ou peut-être je confonds avec quelque
chose d'autre -- je sais que j'ai lu quelque chose du genre dans
Vandevoorde et Josuttis, mais c'est difficile à retenir tous ces
détails, quand on est obligé à travailler principalement avec un
compilateur qui ne les comprend pas, et qu'on ne s'en sert donc
jamais. (Ça doit dépendre des gens, mais je sais que moi, pour
retenir quelque chose, il faut que je m'en sers concrètement.)
| Quote: | On pourrait faire une règle disant que c'est invalide
uniquement si la fonction est choisie, mais je soupçonne que
cela créerait toujours de la confusion. Je pense que la
solution est de simplement autoriser ces choses là. La
restriction est artificielle.
|
En plus, tu ne peux jamais casser du code en enlevant une
restriction:-). (Comme tu sais, le code existant est une
préoccupation importante chez moi.)
| Quote: | Ah, en ce qui concerne le core issue en question il n'y a pas
encore de numéro public mais c'est devant le CWG (i.e.
reflecteur). Note aussi l'explication
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#278
de Mike Miller tendrait à supporter la vision qu'on peut
mangler une énumération, même si elle n'a pas de nom 
|
Je ne vois pas d'explication de Mike Miller là -- seulement des
commentaires de moi-même et de John Skaller.
On a une partie d'un problème parce que C se base sur l'idée des
types « compatibles », c-à-d plus ou moins l'identité
structurelles des types. C++ essaie d'aller dans la direction de
l'identité par nom. Mais j'ai parfois l'impression qu'on n'y a
pas formalisé assez. Il faudrait éventuellement définir un
concepte de linkage pour les types, par exemple. Ou au moins
définir exactement quand deux types n'en sont qu'un, et quand
ils ne le sont pas.
Aussi, je crois que essayer de définir l'identité des types par
la façon que fonctionne le mangling, c'est un peu d'inverser les
priorités -- il faudrait définir le mangling en fonction des
règles d'identité des types.
--
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
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon May 16, 2005 3:12 pm Post subject: Re: enums anonymes |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] writes:
[...]
| Quote: | Comme j'ai dit, quelque part quelqu'un a confondu « type » et
« nom » et a créé cette confusion. Au debut « linkage »
concernait les noms, puis il a été étendu aux types de
fonctions (contrairement à l'avertissement de l'ARM) ; et
maintenant il est impliciement utilisé pour autres choses.
En effet, je crois que tu as mis ton doigt sur le problème. Un
template dépend des types, non des « noms ». Seulement, comme tu
dis, ailleurs dans la norme, les types n'ont pas de linkage. Et
|
CWG a récemment pris soin de « fixer » cela :-(
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#389
Je crois que le groupe AFNOR C++ devrait regarder ce sujet de près et
proposer une formulation différente -- on n'a pas beaucoup de temps,
si le calendrier informellement adopté à Lillehammer marche, il nous
reste 4 ou 5 meetings avant la production du draft final.
J'essaierai d'écrire quelque chose (résumé + proposition) et le poster
dans ce groupe, d'ici la semaine prochaine (mais je suis un peu limité
en ce moment).
| Quote: | plus généralement, si on a déjà un type, que importe son nom.
(Ou ses noms -- grace aux typedef's, un type peut avoir
plusieurs noms aussi -- dont certains sans linkage, et d'autres
avec.)
Le problème avec le code est que pour faire la résolution de
surcharge de « << », le compilateur doit considérer les «
operator<< » dans la portée ainsi que ceux qui sont câblés. En
particulier, pour celui qui est template, le compilateur doit
déduire les arguments de templates. Or cette phase
(préliminaire) déduit un type non nommé, alors le compilateur
se plaint -- même et surtout si la fonction correspondante
n'est jamais utilisée. Intéressant, n'est-ce pas ?
Mais il me semble qu'il y avait quelque part une règle qui
disait que l'impossibilité de pouvoir deduire un template n'est
pas une erreur -- on écarte le template de l'ensemble de
surcharge, et on continue.
|
Tu parles probablement de §14.8.3/1:
A function template can be overloaded either by (non-template)
functions of its name or by (other) function templates of the same
name. When a call to that name is written (explicitly, or implicitly
using the operator notation), template argument deduction (14.8.2)
and checking of any explicit template arguments (14.3) are performed
for each function template to find the template argument values (if
any) that can be used with that function template to instantiate a
function template specialization that can be invoked with the call
arguments. For each function template, if the argument deduction and
checking succeeds, the templatearguments (deduced and/or explicit)
are used to instantiate a single function template specialization
which is added to the candidate functions set to be used in overload
resolution. If, for a given function template, argument deduction
fails, no such function is added to the set of candidate functions
for that template. The complete set of candidate functions includes
all the function templates instantiated in this way and all of the
non-template overloaded functions of the same name. The function
template specializations are treated like any other functions in the
remainder of overload resolution, except as explicitly noted in
13.3.3.133)
accompagné de §14.8.2/2. Mais dans la longue liste des cas spéciaux
donnée en §14.8.2/2, l'utilisation de type non nommé ou de type local
n'est pas mentionné, donc cela résulte bien en une erreur (ill-formed)
et non une simulation (deduction fail).
| Quote: | Ou peut-être je confonds avec quelque
chose d'autre -- je sais que j'ai lu quelque chose du genre dans
Vandevoorde et Josuttis, mais c'est difficile à retenir tous ces
détails, quand on est obligé à travailler principalement avec un
compilateur qui ne les comprend pas, et qu'on ne s'en sert donc
jamais. (Ça doit dépendre des gens, mais je sais que moi, pour
retenir quelque chose, il faut que je m'en sers concrètement.)
|
Je présume que tu parles de que certains appelent SFINAE et qui est
basé sur les deux paragraphes cités ci-haut.
| Quote: |
On pourrait faire une règle disant que c'est invalide
uniquement si la fonction est choisie, mais je soupçonne que
cela créerait toujours de la confusion. Je pense que la
solution est de simplement autoriser ces choses là. La
restriction est artificielle.
En plus, tu ne peux jamais casser du code en enlevant une
restriction:-). (Comme tu sais, le code existant est une
préoccupation importante chez moi.)
|
Quand on est dans le territoire de SFINAE, il faut faire extrêment
attention car il s'agit de la manipulation des « overload set », donc
on pourrait facilement changer la sémantique d'un programme.
Dans le cas qui nous occupe, cela n'est pas du SFINAE parce que
justement cela n'est pas son domaine. Donc on peut enveler cette
restriction sans effectivement casser du code existant.
| Quote: | Ah, en ce qui concerne le core issue en question il n'y a pas
encore de numéro public mais c'est devant le CWG (i.e.
reflecteur). Note aussi l'explication
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#278
de Mike Miller tendrait à supporter la vision qu'on peut
mangler une énumération, même si elle n'a pas de nom :-)
Je ne vois pas d'explication de Mike Miller là -- seulement des
commentaires de moi-même et de John Skaller.
|
Tu as absolument raison -- pour une raison quelconque (probablement
fatigue) -- j'ai lu Mike Miller au lieu de John Max Skaller.
| Quote: | On a une partie d'un problème parce que C se base sur l'idée des
types « compatibles », c-à-d plus ou moins l'identité
structurelles des types. C++ essaie d'aller dans la direction de
l'identité par nom. Mais j'ai parfois l'impression qu'on n'y a
pas formalisé assez. Il faudrait éventuellement définir un
concepte de linkage pour les types, par exemple. Ou au moins
définir exactement quand deux types n'en sont qu'un, et quand
ils ne le sont pas.
|
ou une notion claire de « forme normale » -- c'est ce que manipule les
schémas de mangling -- où toutes les références à une entité se font
par des formes normales. Par exemple, pour une classe nommée c'est le
nom de la classe (et non un typedef), pour un pointer T* c'est pT (ou
quelque chose de ressemblant), ainsi de suite.
| Quote: | Aussi, je crois que essayer de définir l'identité des types par
la façon que fonctionne le mangling, c'est un peu d'inverser les
priorités -- il faudrait définir le mangling en fonction des
règles d'identité des types.
|
Absolument.
Es-tu d'attaque pour ça ? :-)
-- Gaby
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Tue May 17, 2005 7:56 am Post subject: Re: enums anonymes |
|
|
Gabriel Dos Reis wrote:
| Quote: | kanze (AT) gabi-soft (DOT) fr writes:
[...]
| > Comme j'ai dit, quelque part quelqu'un a confondu « type »
| > et « nom » et a créé cette confusion. Au debut «
| > linkage » concernait les noms, puis il a été étendu aux
| > types de fonctions (contrairement à l'avertissement de
| > l'ARM) ; et maintenant il est impliciement utilisé pour
| > autres choses.
| En effet, je crois que tu as mis ton doigt sur le problème.
| Un template dépend des types, non des « noms ». Seulement,
| comme tu dis, ailleurs dans la norme, les types n'ont pas de
| linkage. Et
CWG a récemment pris soin de « fixer » cela :-(
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#389
Je crois que le groupe AFNOR C++ devrait regarder ce sujet de
près et proposer une formulation différente -- on n'a pas
beaucoup de temps, si le calendrier informellement adopté à
Lillehammer marche, il nous reste 4 ou 5 meetings avant la
production du draft final. J'essaierai d'écrire quelque chose
(résumé + proposition) et le poster dans ce groupe, d'ici la
semaine prochaine (mais je suis un peu limité en ce moment).
|
En effet. La formulation proposée là ne me satisfait pas
complètement moi non plus. Mais je ne sais pas si je saurais
faire mieux.
| Quote: | | plus généralement, si on a déjà un type, que importe son
| nom. (Ou ses noms -- grace aux typedef's, un type peut avoir
| plusieurs noms aussi -- dont certains sans linkage, et
| d'autres avec.)
| > Le problème avec le code est que pour faire la résolution
| > de surcharge de « << », le compilateur doit considérer les
| > « operator<< » dans la portée ainsi que ceux qui sont
| > câblés. En particulier, pour celui qui est template, le
| > compilateur doit déduire les arguments de templates. Or
| > cette phase (préliminaire) déduit un type non nommé, alors
| > le compilateur se plaint -- même et surtout si la fonction
| > correspondante n'est jamais utilisée. Intéressant,
| > n'est-ce pas ?
| Mais il me semble qu'il y avait quelque part une règle qui
| disait que l'impossibilité de pouvoir deduire un template
| n'est pas une erreur -- on écarte le template de l'ensemble
| de surcharge, et on continue.
Tu parles probablement de §14.8.3/1:
A function template can be overloaded either by (non-template)
functions of its name or by (other) function templates of the same
name. When a call to that name is written (explicitly, or
implicitly
using the operator notation), template argument deduction (14.8.2)
and checking of any explicit template arguments (14.3) are
performed
for each function template to find the template argument values (if
any) that can be used with that function template to instantiate a
function template specialization that can be invoked with the call
arguments. For each function template, if the argument deduction
and
checking succeeds, the templatearguments (deduced and/or explicit)
are used to instantiate a single function template specialization
which is added to the candidate functions set to be used in
overload
resolution. If, for a given function template, argument deduction
fails, no such function is added to the set of candidate functions
for that template. The complete set of candidate functions includes
all the function templates instantiated in this way and all of the
non-template overloaded functions of the same name. The function
template specializations are treated like any other functions in
the
remainder of overload resolution, except as explicitly noted in
13.3.3.133)
accompagné de §14.8.2/2. Mais dans la longue liste des cas
spéciaux donnée en §14.8.2/2, l'utilisation de type non nommé
ou de type local n'est pas mentionné, donc cela résulte bien
en une erreur (ill-formed) et non une simulation (deduction
fail). | Ou peut-être je confonds avec quelque | chose d'autre
-- je sais que j'ai lu quelque chose du genre dans |
Vandevoorde et Josuttis, mais c'est difficile à retenir tous
ces | détails, quand on est obligé à travailler principalement
avec un | compilateur qui ne les comprend pas, et qu'on ne
s'en sert donc | jamais. (Ça doit dépendre des gens, mais je
sais que moi, pour | retenir quelque chose, il faut que je
m'en sers concrètement.)
Je présume que tu parles de que certains appelent SFINAE et
qui est basé sur les deux paragraphes cités ci-haut.
|
C'est tout à fait ça. Je savais l'avoir vu sous un acronyme
affreux plusieurs fois, et j'avais reconnu que l'acronyme
correspondait à ce que j'avais vu dans Vandevoorde et Josuttis,
mais je ne me suis jamais rappelé des détails, ni régardé les
passages exacts dans la norme.
Si le cas en question ne se trouve pas dans la liste des cas
concernés, est-ce que ça ne serait qu'une oublie, et non
exprès ? Ce qui veut dire qu'on pourrait l'ajouter avec un
simple TC. Parce qu'il me semble que l'exemple devait marcher.
| Quote: | | > On pourrait faire une règle disant que c'est invalide
| > uniquement si la fonction est choisie, mais je soupçonne
| > que cela créerait toujours de la confusion. Je pense que
| > la solution est de simplement autoriser ces choses là. La
| > restriction est artificielle.
| En plus, tu ne peux jamais casser du code en enlevant une
| restriction:-). (Comme tu sais, le code existant est une
| préoccupation importante chez moi.)
:-)
Quand on est dans le territoire de SFINAE, il faut faire
extrêment attention car il s'agit de la manipulation des
« overload set », donc on pourrait facilement changer la
sémantique d'un programme. Dans le cas qui nous occupe, cela
n'est pas du SFINAE parce que justement cela n'est pas son
domaine. Donc on peut enveler cette restriction sans
effectivement casser du code existant.
|
C'est vrai qu'ajouter quelque chose sur le overload set peut
bien casser du code existant. J'avoue que je suis assez peu
sensibilisé à ce problème, parce que je surcharge assez peu, et
quand je surcharge, je m'assure que toutes les fonctions ont la
même sémantique -- que le programme est « correct » quelque soit
la fonction appelée.
Mais bon, ce n'est que moi. Je suis bien d'accord que c'est une
question qu'il faut prendre en compte. Parmi d'autres : si la
situation actuelle est floue, et que différents compilateurs ont
déjà des comportements différents, il faut de toute façon faire
quelque chose.
[...]
| Quote: | | Aussi, je crois que essayer de définir l'identité des types
| par la façon que fonctionne le mangling, c'est un peu
| d'inverser les priorités -- il faudrait définir le mangling
| en fonction des règles d'identité des types.
Absolument.
Es-tu d'attaque pour ça ?
|
Je crois que je pourrais y aider -- je suis trop loin de la
normalisation et des compilateurs depuis trop longtemps pour m'y
sentir tout à fait à l'aise, mais je suis (enfin) arrivé à un
point où je pourrais y consacrer un peu de temps.
--
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
|
|
| Back to top |
|
|
google@vandevoorde.com
Guest
|
| Posted: Tue May 17, 2005 2:25 pm Post subject: Re: enums anonymes |
|
|
k... (AT) gabi-soft (DOT) fr wrote:
[...]
| Quote: | C'est tout à fait ça. Je savais l'avoir vu sous un acronyme
affreux plusieurs fois, et j'avais reconnu que l'acronyme
correspondait à ce que j'avais vu dans Vandevoorde et Josuttis,
mais je ne me suis jamais rappelé des détails, ni régardé les
passages exacts dans la norme.
Si le cas en question ne se trouve pas dans la liste des cas
concernés, est-ce que ça ne serait qu'une oublie, et non
exprès ? Ce qui veut dire qu'on pourrait l'ajouter avec un
simple TC. Parce qu'il me semble que l'exemple devait marcher.
|
Probablement. SFINAE a une histoire un peu compliquee,
mais plusieurs fois deja le CWG a ajoute a la liste des
simples proprietes de types (le cas discute est "simple").
La grande limitation de SFINAE sont les erreur d'expressions.
Par example:
template<class T> void f(T, int (*)[sizeof(g(T))];
Le probleme ici est que l'analyse SFINAE maintenant doit
prendre en compte la possibilite d'instantiations complexe
(e.g., "g(T)" sera peut-etre un a appel d'une fonction avec
un argument par default qui doit etre instantie), et ne pas
generer une erreure quand on aboutit a un probleme a la
fin d'une analyse pareille est trop couteux pour la
technologie standard des compilos.
David
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Tue May 17, 2005 4:50 pm Post subject: Re: enums anonymes |
|
|
[email]google (AT) vandevoorde (DOT) com[/email] writes:
| Quote: | k... (AT) gabi-soft (DOT) fr wrote:
[...]
C'est tout à fait ça. Je savais l'avoir vu sous un acronyme
affreux plusieurs fois, et j'avais reconnu que l'acronyme
correspondait à ce que j'avais vu dans Vandevoorde et Josuttis,
mais je ne me suis jamais rappelé des détails, ni régardé les
passages exacts dans la norme.
Si le cas en question ne se trouve pas dans la liste des cas
concernés, est-ce que ça ne serait qu'une oublie, et non
exprès ? Ce qui veut dire qu'on pourrait l'ajouter avec un
simple TC. Parce qu'il me semble que l'exemple devait marcher.
Probablement. SFINAE a une histoire un peu compliquee,
mais plusieurs fois deja le CWG a ajoute a la liste des
simples proprietes de types (le cas discute est "simple").
|
Mais, je suis content que le cas en question (utilisation de type non
nommé comme argument de template) ne soit pas couvert par SFINAE.
Concretement, cela veut dire qu'on peut enlever cette limitation sans
changer les « overload set. »
| Quote: | La grande limitation de SFINAE sont les erreur d'expressions.
Par example:
template<class T> void f(T, int (*)[sizeof(g(T))];
Le probleme ici est que l'analyse SFINAE maintenant doit
prendre en compte la possibilite d'instantiations complexe
(e.g., "g(T)" sera peut-etre un a appel d'une fonction avec
un argument par default qui doit etre instantie), et ne pas
generer une erreure quand on aboutit a un probleme a la
fin d'une analyse pareille est trop couteux pour la
technologie standard des compilos.
|
Well, je crois que « couteux » est relatif Si un programme utilise
cette construction, il en paie le prix. Un programme qui ne
l'utilise pas ne serait pas pénalisé. Tous les programs C++
n'utilisent pas cette technique, mais je crois qu'au fond elle est
utile (évidemment, si on lui donne une autre syntaxe )
La raison pour laquelle GCC n'émettait d'erreur dans les versions
antérieures est que GCC était capable de faire une analyse pareille
(évidemment sans perfection) arbitraire sans produire d'erreur -- on a
un paramètre « complain » qui demande au compilateur d'emettre un
diagnostique ou non. (Une autre limitation de GCC est le bug dans
l'ABI qui a oublié qu'on pouvait avoir une expression arbitraire dans
un sizeof). Ce problème pointe son nez depuis divers points (voir
concepts, decltype, actuellement dans C++03) que je pense qu'on
devrait juste prendre le taureau par les cornes.
De manière génerale, je crois que l'approche qui consiste à définir un
« linkage » pouor les types introduit plus de problèmes et limitation
qu'il n'en résoud. Comme je l'ai dit avant, je pense qu'on devrait
faire autrement -- définir les formes normales indépendant de linkage
(qui est en quelque sort le prête-nom de « mangling », si on inclut la
notion de signature).
-- Gaby
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
