Discussion :

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[bretus]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[koala01]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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" )

[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 ? )

[koala01]

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 ? )

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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
C'est pour cela que je demande si j'ai loupé quelque chose

[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