Variadic template : ai-je loupé quelque chose ou est-ce un bug?

Version imprimable

Salut,

En préparant une réponse à cette discussion, j'ai été confronté à un comportement qui me semble étrange de la part de gcc...

En effet, si j'exécute le code

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
#include <string>
#include <iostream>
template<typename ...Args>
void foo(Args ... args)
{
    std::cout<<"stopping with "<<sizeof...(args)<< " unused arguments"<<std::endl;
}
template<typename ...Args>
void foo(int i, Args ... args)
{
    std::cout<<"using i = "<<i
             <<", left "<<sizeof...(args)<<" argument more"<<std::endl;
    foo(args...);
}
template<typename ... Args>
void foo(std::string const & s, Args...args)
{
    std::cout<<"using the "<<s<<" string, left "
             <<sizeof...(args)<<" argument more"<<std::endl;
    foo(args...);
}
int main()
{
 
    foo<int, int,int, int, std::string , int, int >(1, 2, 3, 4,5 ,
                                                   "salut", 6, 7 );
    return 0;
}

l'exécution s'arrpête après avoir utiliser l'argument "salut", en me disant qu'il reste 2 arguments inutilisés.

Par contre, si je rajoute une déclaration des fonctions sous la forme de

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include <iostream>
#include <string>
template<typename ...Args>
void foo(int i, Args ... args);
template<typename ...Args>
void foo(std::string const & s, Args...args);
template<typename ...Args>
void foo(Args ... args)
{
    std::cout<<"stopping with "<<sizeof...(args)<< " unused arguments"<<std::endl;
}
template<typename ... Args>
void foo(std::string const & s, Args...args)
{
    std::cout<<"using the "<<s<<" string, left "
             <<sizeof...(args)<<" argument more"<<std::endl;
    foo(args...);
}
template<typename ...Args>
void foo(int i, Args ... args)
{
    std::cout<<"using i = "<<i
             <<", left "<<sizeof...(args)<<" argument more"<<std::endl;
    foo(args...);
}
int main()
{
 
    foo<int, int,int, int, std::string , int, int >(1, 2, 3, 4,5 ,
                                                   "salut", 6, 7 );
    return 0;
}

l'exécution va jusqu'à son terme...

Je me serais pourtant attendu, étant donné que la définition de fonction vaut déclaration, à ce que le premier code fonctionne correctement !!!

Alors, selon vous, aurais-je loupé quelque chose, ou s'agit-il d'un bug de gcc :question:

Ton premier code arrive à terme avec ceci en sortie avec gcc 4.6.3

Code:

1
2
3
4
5
6
7
 
using i = 1, left 7 argument more
using i = 2, left 6 argument more
using i = 3, left 5 argument more
using i = 4, left 4 argument more
using i = 5, left 3 argument more
stopping with 3 unused arguments

Citation:
Envoyé par bretus
Ton premier code arrive à terme avec ceci en sortie avec gcc 4.6.3
Code:

1 2 3 4 5 6 7 using i = 1, left 7 argument more using i = 2, left 6 argument more using i = 3, left 5 argument more using i = 4, left 4 argument more using i = 5, left 3 argument more stopping with 3 unused arguments
Ben oui, et c'est justement là le problème...

Je me serais attendu à ce que le premier code fournisse exactement la même sortie que le second, vu que les surcharges représentent le "best match" à chaque fois :aie:

Mais, avant d'envoyer un rapport de bug, j'aimerais savoir ce que vous en pensez, au cas où je serais passé à coté d'un détail ;)

(note que j'ai ce comportement que je crois erroné avec gcc 4.7.1 "build perso" ;))

17/12/2012, 08h50
gbdivers

Même résultat que Bretus : le programme s'arrête avant d'utiliser la spécialisation pour string, pas après. Donc résultat normale, la fonction spécialisée pour int ne peut pas appeler la spécialisation pour string (qui est déclarée après) et appelle donc la version non spécialisée (le stop)
Donc pas de bug de notre côté (gcc 4.8 linux chez moi). Teste avec un build non perso (ou poste un draft pour modifier la norme C++ pour qu'elle respecte ton build perso ? :aie:)
17/12/2012, 08h59
koala01
Citation:

Envoyé par gbdivers

Même résultat que Bretus : le programme s'arrête avant d'utiliser la spécialisation pour string, pas après. Donc résultat normale, la fonction spécialisée pour int ne peut pas appeler la spécialisation pour string (qui est déclarée après) et appelle donc la version non spécialisée (le stop)
Donc pas de bug de notre côté (gcc 4.8 linux chez moi). Teste avec un build non perso (ou poste un draft pour modifier la norme C++ pour qu'elle respecte ton build perso ? :aie:)

En fait, je me doute bien que toutes les versions actuelles présentent le meme comportement, donc cela ne sert pas à grand chose de me confirmer que c'est celui que vous obtenez.

Par contre, étant donné que tout est inline, il ne devrait pas y avoir une approche plus ou moins SFINAE qui ferait que les deux codes devraient réagir de la même manière :question:

Parce que l'on est quand même bien d'accord sur le fait que le compilateur commence à implémenter les fonctions quand il rencontre l'appel dans main.

A ce moment là, il a déjà vu les définitions de toutes les surcharge et doit donc choisir le best match, même si la surcharge utilisant la std::string arrive après celle utilisant int.

Autrement, cela veut dire que tu auras un comportement différent en fonction de l'ordre de tes paramètrex ou de l'ordre dans lequel tu définis tes surcharges, et ca, ca ne me semble pas normal du tout:

Cela signifierait, avec le code tel qu'il est dans mon premier exemple, que si tu remplace l'appel par
Code:

1 2 foo<std::string , int, int,int, int, int, int >( "salut",1, 2, 3, 4,5 , 6, 7 );
tu verrais tous les arguments...

Ca me semble quand meme un peu suspect, non :question:
C'est pour cela que je demande si j'ai loupé quelque chose ;)
17/12/2012, 09h04
gbdivers

Ok, je comprend ce que tu veux dire... je pensais que tu disais que chez toi, le compilateur s'arrêtait après la spécialisation string, pas avant (donc un résultat différent de nous)
Du coup, je sais pas trop
17/12/2012, 09h09
koala01

Pas de problème pour moi ;)

Ah, et, pour info, le "build perso", c'est parce que je me suis amusé à compiler une version "multilib" qui compile par défaut en bits, rien de plus :D
17/12/2012, 22h52
JolyLoic

Ce comportement me semble normal. Ce qui compte pour la recherche de noms, c'est le point de définition, pas le point d'instanciation (autrement, deux instanciations d'un même template avec les mêmes paramètres pourraient être différentes, ce qui ferait désordre...). Ton exemple me semble assez proche à celui du 14.6.3, le fait que les templates soient variadiques n'y change rien.

Citation:

Envoyé par JolyLoic

Ce comportement me semble normal. Ce qui compte pour la recherche de noms, c'est le point de définition, pas le point d'instanciation (autrement, deux instanciations d'un même template avec les mêmes paramètres pourraient être différentes, ce qui ferait désordre...). Ton exemple me semble assez proche à celui du 14.6.3, le fait que les templates soient variadiques n'y change rien.

Cela peut sembler logique, sauf qu'en l'occurrence, ce n'est même pas le point de définition qui joue, mais le point de déclaration :?

Et c'est ca qui m'inquiète le plus car cela signifie que l'ordre des déclarations puisse etre important :p

Or , je viens de vérifier avec le code
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 #include <iostream> #include <string> template<typename ...Args> void foo(Args ... args); template<typename ...Args> void foo(int i, Args ... args); template<typename ...Args> void foo(std::string const & s, Args...args); template<typename ...Args> void foo(Args ... args) { std::cout<<"stopping with "<<sizeof...(args)<< " unused arguments"<<std::endl; } template<typename ... Args> void foo(std::string const & s, Args...args) { std::cout<<"using the "<<s<<" string, left " <<sizeof...(args)<<" argument more"<<std::endl; foo(args...); } template<typename ...Args> void foo(int i, Args ... args) { std::cout<<"using i = "<<i <<", left "<<sizeof...(args)<<" argument more"<<std::endl; foo(args...); } int main() { foo<int, int,int, int, std::string , int, int >(1, 2, 3, 4,5 , "salut", 6, 7 ); return 0; }
et, indépendamment de la positon des définitions, l'ordre des déclarations est important, dans le sens où tous les éléments ne sont affichés que si la déclaration de la fonction ne prenant que le variadic se trouve en dernière position.

Le problème, c'est que cela sous entend que, si tu venais à avoir les trois fonctions déclarées dans des fichiers différents, l'ordre d'inclusion des fichiers serait important même si tu n'as qu'un seul fichier d'implémentation.

Et ca, ca reviendrait à peu près à dire que tu ne peux pas inclure <iostream> avant d'avoir inclus <string> 8O.

Je suis tout à fait prêt à te croire lorsque tu cite le paragraphe de la norme, mais, si c'est le seul qui entre en ligne de compte, alors, il y a effectivement peut etre un problème au niveau de la norme, parce que cela va à l'encontre du principe selon lequel l'ordre d'inclusion ne doit pas influer, sauf cas particulier :aie:

Maintenant, je connais suffisamment la norme pour au moins savoir qu'il faut être particulièrement attentif en la lisant, car on a vite fait de passer sur un paragraphe important aussi ;)

Et c'est pour cela que je reste quand meme plus ou moins sceptique .

Au temps pour moi, j'avais pas fait attention :aie:

L'ordre de déclaration ne change rien, et on a le comportement attendu (tous les arguments affichés) quel que soit l'ordre de déclaration des fonctions.

21/12/2012, 18h24
Iradrille

Pour info ton premier code (celui sans les déclarations préalables) utilise tous les arguments sous ICC.
Donc l'un des deux compilos a un comportement erroné.
Reste à savoir lequel ^^"
21/12/2012, 18h30
koala01

Citation:

Envoyé par Iradrille

Pour info ton premier code (celui sans les déclarations préalables) utilise tous les arguments sous ICC.
Donc l'un des deux compilos a un comportement erroné.
Reste à savoir lequel ^^"

Ben, à vrai dire, c'est à ce genre de comportement que je me serais attendu :p
21/12/2012, 18h57
koala01

Pour info, dans le doute, j'ai introduit un rapport de bug... nous verrons ce que l'équipe de dev en pense ;)

Je passe le sujet en résolu, mais n'hésitez pas à intervenir pour la cause ;)
21/12/2012, 19h22
germinolegrand
Pour avoir pas mal bossé avec les variadics, j'ai le regret de te dire que ton code dans bugzilla a strictement le comportement attendu, un autre comportement serait illégal et me surprendrait énormément ^^.
Il est le résultat du SFINAE, à la 6e itération, tu demandes explicitement comme premier type template un int, mais tu demandes à ce que le premier argument soit une std::string. Comme le compilo ne connait pas de spécialisation
Code:

1 2 template<class ... Args> foo<int, Args...>(std::string, Args ... args);
il applique le SFINAE et va chercher la seule signature correcte, c'est à dire
Code:

1 2 template<class ... Args> foo<Args...>(Args ... args);

Tu sembles avoir loupé la spécialisation qui prend une std::string en premier parametre...
Le compilateur devrait (SFINAE aidant) choisir
Code:

1 2 3 4 5 6 7 template<typename ...Args> void foo(int i, Args ... args) { std::cout<<"using i = "<<i <<", left "<<sizeof...(args)<<" argument more"<<std::endl; foo(args...); }
pour les valeurs 1 à 7 et devrait retomber sur
Code:

1 2 3 4 5 6 7 template<typename ...Args> void foo(std::string const & s, Args...args) { std::cout<<"using the "<<s<<" string, left " <<sizeof...(args)<<" argument more"<<std::endl; foo(args...); }
pour "hello", non?

Note que je ne spécialise jamais le template, je me contente de surcharger la fonction ;)

[EDIT]Pour autant que j'aie bien compris, quelle que soit la manière dont j'appelle la fonction à la base, il devrait dérouler les paramètres variadiques sous une forme proche de

int, int,int, int, std::string , int, int==> (int, Args...)
int,int, int, std::string , int, int==> (int, Args...)
int, int, std::string , int, int==> (int, Args...)
int, std::string , int, int==> (int, Args...)
std::string , int, int==> (std::string, Args...)
int, int==> (int, Args...)
int==> (int, Args...)
(rien)==> (Args...)
Comme il n'y a aucune spécialisation de la fonction, mais seulement des surcharges, lorsqu'il arrive à std::string comme premier paramètre, ce devrait être la surcharge adéquate ( foo( std :: string const &, ...args) ) qui devrait etre appelée, surtout à cause du SFINAE.

Et comme le fait remarquer gbdivers, ton raisonnement semble cohérent, mais alors, comment expliquerions nous que la simple déclaration "anticipée" de la fonction fasse réagir le code différemment :question:

21/12/2012, 19h29
gbdivers

:koi: ça a l'air crédible comme explication :)
Par contre, pourquoi la déclaration anticipée permet de résoudre le problème ?

Loic a donner une explication, elle me semble correcte aussi (surtout appuyer par l'exemple de la norme auquel il fait référence) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 void g(double); void h(); template<class T> class Z { public: void f() { g(1); // calls g(double) h++; // ill-formed: cannot increment function; // this could be diagnosed either here or // at the point of instantiation } }; void g(int); // not in scope at the point of the template // definition, not considered for the call g(1)
De la même manière dans ton code, il est à chaque fois dans l'instanciation du "deuxième" template, donc il ne connait pas le "troisième" et il appel donc une instanciation du "premier" quand il ne peut plus utiliser une instanciation du deuxième".

Quant tu fais une déclaration de tes fonctions template, lorsqu'il est dans une instance du "deuxième" template, le compilateur utilise les trois noms pour appliquer l'algo de sélection.

Ca peut sembler restrictif dans le sens où les PI peuvent être localisés de manière à "voir" les trois noms, cependant comme la norme ne fixe pas totalement les PI, imposer les comportements par rapport aux définitions et pas aux PI évite d'introduire des UB de partout.

@Koala: Tu devrais virer la liste explicite de paramètre template de ton appel à foo, ca évitera d'introduire des problèmes supplémentaire (ie mal compté les types par rapport au pramètre). Normalement le compilo déduit tout seul.

Si ce n'est que SFINAE permet, justement de "descendre" dans les définitions...

Pour rappel : SFINAE = Single Failure Is Not An Error, donc, avec le code que j'ai donné dés le départ (et que j'ai copié sur bugzilla), à savoir :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #include <string> #include <iostream> template<typename ...Args> void foo(Args ... args) { std::cout<<"stopping with "<<sizeof...(args)<< " unused arguments"<<std::endl; } template<typename ...Args> void foo(int i, Args ... args) { std::cout<<"using i = "<<i <<", left "<<sizeof...(args)<<" argument more"<<std::endl; foo(args...); } template<typename ... Args> void foo(std::string const & s, Args...args) { std::cout<<"using the "<<s<<" string, left " <<sizeof...(args)<<" argument more"<<std::endl; foo(args...); } int main() { foo<int, int,int, int, std::string , int, int >(1, 2, 3, 4,5 , "salut", 6, 7 ); return 0; }
il commence par avoir un int, qu'il gère comme tel, et "un nombre inconnus de paramètres dont il ignore, et il utilise la fonction foo(int i, Args ... args)

Pour les paramètres 2, 3, 4 et 5, c'est le meme principe

Puis il arrive à
"salut", 6, 7, ce qui, de son coté signifie "une chaine de caractères et une série de paramètre dont il ignore tout"...

Ca tombe bien, il a justement une surcharge de la fonction qui permet cela sous la forme de
Code:

1 2 3 4 5 6 7 template<typename ... Args> void foo(std::string const & s, Args...args) { std::cout<<"using the "<<s<<" string, left " <<sizeof...(args)<<" argument more"<<std::endl; foo(args...); }
Il devrait donc l'utiliser, au lieu de tomber sur le cas de base

Et, enfin, il devrait se retrouver avec les deux derniers entiers, reconnus comme tels, et terminer la boucle, pour ne tomber dans le cas de base que... lorsqu'il n'y a plus d'argument à traiter.

Ce qui me fait dire qu'il y a réellement un problème n'est pas tant le fait que le comportement final va dépendre des déclarations de fonctions (quoi que...), mais bien le fait que, si tu change un tout petit peu l'ordre de définition des fonctions, en définissant
Code:

1 2 3 4 5 6 7 template<typename ... Args> void foo(std::string const & s, Args...args) { std::cout<<"using the "<<s<<" string, left " <<sizeof...(args)<<" argument more"<<std::endl; foo(args...); }
avant de définir
Code:

1 2 3 4 5 6 7 template<typename ...Args> void foo(int i, Args ... args) { std::cout<<"using i = "<<i <<", left "<<sizeof...(args)<<" argument more"<<std::endl; foo(args...); }
tu auras un comportement différent, alors que l'ordre d'implémentation ne devrait pas avoir d'impact...

Je suis tout prêt à accepter vos explications et peut etre que le problème est "ailleurs", mais, pour l'instant on se heurte à un problème qui ne devrait pas arriver : le fait que l'ordre d'implémentation de fonction au niveau d l'unité de compilation puisse changer le comportement de l'application :aie:

Je viens de regarder de plus près, j'ai quelques pistes, mais rien de bien certains.

Premièrement le passage que cite Loic n'est pas vraiment applicable dans ce cas, ce passage fait référence au noms non-dépendant, or f(arg...) est une expression qui dépend des paramètres template.

Dans ce cas le lookup est faite au moment de l'instanciation depuis, à la fois, la définition et le POI.

Ce qui fait que selon la localisation des POI la spécialisation nécessaire fera ou non parti du set (le SFINAE n'intervient que pour inclure ou non une spécialisation dans le set, il ne permet pas de voir plus "loin").

D'autre part la norme spécifie (ODR) qui si deux POI donnent deux comportements différent, alors le programme est mauvais mais que le compilateur n'a pas à le signaler (dans la pratique le compilateur doit prendre un POI parmis tout ceux sélectionner, d'où un résultat "aléatoire"). Néanmoins, il semblerait que les compilateurs utilisent souvent des POI en fin de TU, donc ce problème part quelque peu (ca n'en reste pas moins que le programme est faux).

Un dernier point est que le lookup effectué depuis le POI est ADL, donc même si le POI est à la fin, si tes arguments ne sont pas de type déclaré dans le même scope que les fonctions (c'est pas exactement ca, mais le sujet n'est pas l'ADL), les seules trouvées sont celles vue depuis la définition (lookup non ADL).

Illustrons tout ca :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 #include<iostream> namespace N { class C {}; //typedef C A; //Compile, permet d'avoir l'ADL //typedef int A; //Ne compile pas, ne permet pas l'ADL class B {}; //template<class... Arg> //void g(A,Arg...); //Les deux compilent avec ceci //Permet d'être visible depuis la définition //Pas besoin d'ADL void g() { } template<class... Arg> void g(B,Arg... arg) { std::cout << 0; g(arg...); } template<class... Arg> void g(A,Arg...) { std::cout << 1; } } int main() { // g(N::B(),N::A()); // Compile dans certains cas, cf les autres commentaires // Besoin de l'ADL ou d'être visible depuis la définition // g(N::B(),N::A(),N::B()); // Compile tout le temps // Le dernier paramètre assure l'ADL } //Le POI des instanciations est surment ici, donc il "voit" tout

21/12/2012, 21h39
Arzar

Citation:

Envoyé par Iradrille

Pour info ton premier code (celui sans les déclarations préalables) utilise tous les arguments sous ICC.
Donc l'un des deux compilos a un comportement erroné."

On peut ajouter que Visual Studio 2012 + CTP affiche lui aussi tous les arguments avec le premier code.
Edit : Par contre clang se comporte comme GCC.

Citation:

Envoyé par koala01

si tu change un tout petit peu l'ordre de définition des fonctions, en définissant [...] tu auras un comportement différent, alors que l'ordre d'implémentation ne devrait pas avoir d'impact...

Je suis tout prêt à accepter vos explications et peut etre que le problème est "ailleurs", mais, pour l'instant on se heurte à un problème qui ne devrait pas arriver : le fait que l'ordre d'implémentation de fonction au niveau d l'unité de compilation puisse changer le comportement de l'application :aie:

Je pense que c'est là que tu fais fausse route. L'ordre de définition a un impact. Même sans template, sans variadique, ni rien :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #include <iostream> using namespace std; int f1(int i) { return 0; } int g1() {return f1('a'); } int f1(char a) { return 1; } //--------- int f2(int i) { return 0; } int f2(char a) { return 1; } int g2() {return f2('a'); } //--------- int main() { cout << g1() << " " << g2() << endl; }

21/12/2012, 21h58
Flob90

J'ai édité mon message précédent,il semblerait que le POI peut avoir un impact sur le lookup, et j'ai l'impression qu'on est dans ce cas, cf mon message pour les détails.

Source : Norme + Vandevoorde

@Arzar: Visual fait déjà une erreur sur l'exemple de la norme cité par Loic, donc sans même parlé de Variadic il est un peu à la ramasse sur les règles de lookup.
21/12/2012, 22h59
JolyLoic

Citation:

Envoyé par Flob90

Je viens de regarder de plus près, j'ai quelques pistes, mais rien de bien certains.

Premièrement le passage que cite Loic n'est pas vraiment applicable dans ce cas, ce passage fait référence au noms non-dépendant, or f(arg...) est une expression qui dépend des paramètres template.

Je suis d'accord sur ce point, j'ai été trop rapide. Mais ma conclusion reste identique.

Citation:

Envoyé par Flob90

Dans ce cas le lookup est faite au moment de l'instanciation depuis, à la fois, la définition et le POI.

Ce n'est pas vraiment ça. Il y a deux types de sources de recherches :
- La recherche de base, qui a lieu au moment de la définition, pas de l'instanciation,
- La recherche dépendante des arguments, qui elle a lieu dans les namespaces associés aux arguments de la fonction tels qu'ils sont connus au point d'instanciation de la fonction.

Dans notre cas :
- La recherche de base ne trouvera pas la fonction définie après.
- La recherche dépendante du nom ne trouvera rien, car int n'a pas de namespace associé, et string a std comme namespace associé, mais std ne contient pas de fonction f.

Je pense que si à la place de std::string, tu utilisais un type défini dans le même namespace que tes différentes fonctions f, tu aurais donc un résultat différent, puisque là la recherche dépendante du nom pourrait trouver ces fonctions.
21/12/2012, 23h43
germinolegrand

(P.S: SFINAE != Single Failure Is Not An Error mais Substitution Failure Is Not An Error)
22/12/2012, 03h16
Flob90

@Loic: Je pense qu'au final on se rejoint sur la conclusion, j'ai assimilé les deux lieux de recherche car ma source a été la norme et elle le fait :

Citation:

Declarations from namespaces associated with the types of the function arguments both from the
instantiation context (14.6.4.1) and from the definition context.

Mais oui l'une est dépendante de l'ADL et pas l'autre, je le précise dans la suite de mon message et suis en total accord avec toi :

Citation:

Un dernier point est que le lookup effectué depuis le POI est ADL [...] depuis la définition (lookup non ADL).

Mais ton message est surement plus clair que le mien sur ce point :ccool: .

@All: C'est inutile de parler de SFINAE, il n'intervient pas vraiment dans cette situation. Ce qu'on nomme SFINAE n'entre en jeu qu'en présence d'appel explicite à une spécialisation (*), ce n'est pas notre cas. Dans ce cas les paramètre template sont déduits des paramètres de la fonction, il n'y a donc pas d'erreur de substitution (**).

(*) Sauf pour le premier appel du premier exemple du premier message, mais ce n'est pas lui qui pose problème.

(**) On peut peut-être trouver des cas tordues où il rentre en jeu sans appel explicite à une spécialisation, mais là c'est pas le cas.