Instanciation de fonction template et temporaire

Version imprimable

Voir 40 message(s) de cette discussion en une page

18/03/2009, 10h41
MatRem

Instanciation de fonction template et temporaire
Bonjour,

Je me demande pourquoi mes compilateurs (gcc 4.3, et cl de visual c++ 2005) m'instancie cette fonction :
Code:

1 2 3 4 void f(int & val) { std::cout << val << std::endl; }
dans ce cas :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <iostream> template<typename T> void f(T & val) { std::cout << val << std::endl; } int main() { f(int(0)); }
Forcément, avec cette instanciation le code ne peux pas compiler.
Pourquoi le compilateur n'instancie pas cette fonction quand on lui passe un temporaire ?
Code:

1 2 3 4 void f(int const & val) { std::cout << val << std::endl; }
Avec ce comportement, mes compilateurs m'obligent à fournir deux versions de fonction template pour gérer le cas du temporaire :
Code:

1 2 3 4 5 6 7 8 9 10 template<typename T> void f(T & val) { std::cout << val << std::endl; } template<typename T> void f(T const & val) { std::cout << val << std::endl; }
Y'a t il un moyen de factoriser ce genre de code ?

ps : ma fonction f n'est qu'un exemple ultra simplifié ... et effectivement dans ce cas précis la version const suffirait, mais ma question porte sur le cas général ;)
18/03/2009, 11h42
3DArchi

Bonjour,
Je vais répondre de biais :
1/si tu n'as pas besoin de modifier val, pourquoi déclarer la version non const ? Sachant qu'il existe (dans boost) des moyens de supprimer le qualificateur const s'il est déjà présent dans T.
2/ Si tu as besoin de modifier val, alors c'est que tu dois distinguer les 2 comportements.
18/03/2009, 11h53
MatRem

En fait il faut prendre f comme une fonction générique au sens ou elle est indépendante du fait que t soit const ou pas.
Elle appelle seulement des fonctions sur t, et dans T ses fonctions ont des version const et non const (*).

Peut être que je peux donner un exemple si mon explication n'est pas assez concrète ...

(*) : ou pas, et dans ce cas le compilateur pourra effectivement se plaindre de façon justifiée :). Par exemple si on passe un temporaire à f et que seules les fonctions non const sont définies dans T.
18/03/2009, 12h02
3DArchi

Citation:

Envoyé par MatRem

En fait il faut prendre f comme une fonction générique

Ma réponse était générique ;)

Citation:

Envoyé par MatRem

Elle appelle seulement des fonctions sur t, et dans T ses fonctions ont des version const et non const (*).

Soit la fonction suppose qu'elle ne modifie pas l'objet, donc elle n'est supposée qu'appeler des fonctions const et alors le paramètre doit être aussi en const.

Citation:

Envoyé par MatRem

Peut être que je peux donner un exemple si mon explication n'est pas assez concrète ...

Je veux bien. Ca éclairera peut être un peu plus le besoin.
18/03/2009, 12h08
Médinoc

Que se passe-t-il si tu tentes d'invoquer explicitement f<const int>(0) ?

Voiilà un exemple qui permet de comprendre le principe.
Par contre il ne compile pas puisque je ne fournis pas les deux versions de f et que j'utilise un temporaire (c'est fait exprès pour bien voir que dans ce cas je ne devrais pas avoir besoin de fournir les deux) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 template<typename T> void f(T & t) { t.call_the_right_function(); } struct S { void call_the_right_function(); void call_the_right_function() const; }; int main() { f(S()); //Ne compile pas S const s; f(s); //compile trés bien puisque la fonction instanciée est bien void f(T const &) f<S const>(S()); //fonctionne aussi trés bien }

18/03/2009, 12h31
MatRem

@Médinoc : effectivement cela fonctionne trés bien (cf exemple au dessus).

J'aimerais comprendre pourquoi le compilateur n'instancie pas la version const par défaut ...

Le fait de spécifier le type const à l'appel de la fonction est une solution à l'idée de factoriser le code (c'est peut être la seule), mais je la trouve pas trop élégante :) ...
18/03/2009, 12h34
Médinoc
Cette ligne me donne une erreur:

Code:

f<S const> f(S()); //fonctionne aussi trés bien

Citation:

Envoyé par Visual Studio

error C2146: syntax error : missing ';' before identifier 'f'

En supprimant le f supplémentaire, ça compile sans erreur ni warning, alors que f(S()) me donne C4239 (conversion from 'S' to 'S &').

Je me demande si le standard dit quelque chose là-dessus...

Edit: Ceci compile aussi parfaitement:
Code:

1 2 3 4 5 6 const S GetS() { return S(); }; void TestTemplate3() { f(GetS()); }
...Et foire sans le const.
18/03/2009, 12h45
MatRem

Citation:

Envoyé par Médinoc

Cette ligne me donne une erreur:

Oui désolé j'ai écrit un peu vite, j'ai édité l'exemple, c'est ça la ligne qui compile :

Code:

f<S const>(S());

Une autre solution, que je trouve un peu plus élégante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
template<typename T>
inline T const & const_ref(T & ref)
{
   return ref;
}
template<typename T>
inline T const & const_ref(T const & ref)
{
   return ref;
}
 
int main()
{
   f(S()); //Ne compile pas
 
   S const s;
   f(s); //compile trés bien puisque la fonction instanciée est bien void f(T const &)
 
   f<S const>(S()); //fonctionne aussi trés bien
 
   f( const_ref( S() ) );
}

Par contre je ne sais toujours pas pourquoi les compilateurs (plutôt le standard j'imagine) possède ce comportement.

Citation:
Envoyé par MatRem
Une autre solution, que je trouve un peu plus élégante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 template<typename T> inline T const & const_ref(T & ref) { return ref; } template<typename T> inline T const & const_ref(T const & ref) { return ref; } int main() { f(S()); //Ne compile pas S const s; f(s); //compile trés bien puisque la fonction instanciée est bien void f(T const &) f<S const>(S()); //fonctionne aussi trés bien f( const_ref( S() ) ); }
Par contre je ne sais toujours pas pourquoi les compilateurs (plutôt le standard j'imagine) possède ce comportement.
Du coup tu passes toujours par un const. Donc à quoi sert la surcharge en non const...

A permettre ça, en faisant en sorte que f appelle la version call_the_right_function non const ;) :
Code:

1 2 S s; f(s);
D'ailleurs avec const_ref, la surcharge n'est plus nécessaire puisque le compilateur instancie tout seul la bonne version de f (T const & ou T &).

Voilà un exemple complet :
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 template<typename T> void f(T & t) { t.call_the_right_function(); } struct S { void call_the_right_function(); void call_the_right_function() const; }; template<typename T> inline T const & const_ref(T & ref) { return ref; } template<typename T> inline T const & const_ref(T const & ref) { return ref; } int main() { f(const_ref( S() )); //call_the_right_function() const S s; f(s); //call_the_right_function() non const }

Salut,

Je crois qu'il serait temps de reprendre depuis le début en s'intéressant au mot clé const et au concept de "const correctness"...

Le mot clé const va avoir pour effet de signaler au compilateur que l'on ne peut pas modifier le contenu de la variable (ou de l'argument transmis), avec, comme corrolaire, le fait de rajouter certaines restrictions sur l'usage que l'on peut faire de la variable, comme le fait de ne pouvoir utiliser que les fonctions membres qui se sont engagées à ne pas modifier l'objet (qui sont déclarées const);

La transformation d'un objet non constant en un objet constant ne posera jamais de problème du fait que l'on rajoute des restrictions d'utilisation, alors que la transformation d'un objet constant en un objet non constant sera refusée car, justement, cela a pour effet de lever certaines restrictions qui peuvent "venir de loin"...

C'est la raison pour laquelle le principe de "const correctness" conseille largement de préciser systématiquement qu'une variable (ou un argument) n'a pas pour vocation d'être modifié lorsque c'est le cas.

En effet, une fonction dont la déclaration est proche de
Code:

1 2 3 4 5 template<typename> void foo(T const t) { /* ce qui doit être fait, sans modification du contenu de t */ }
sera acceptée qu'elle soit invoquée sous la forme de
Code:

1 2 int i = 3; foo<int> (i);
ou sous la forme de
Code:

1 2 int const j = 5 foo<int>(j);
A cela vient se rajouter le problème des références sur objets...

Pour rappel, une référence est un alias de l'objet référencé, ce qui permet d'éviter une copie lorsqu'un objet est passé en référence ainsi que de s'assurer que toute modification apportée à la référence sera répercutée sur l'objet d'origine.

C'est ainsi que tu peux en arriver à une classe proche de
Code:

1 2 3 4 5 6 7 8 9 class MyClass { public: MyClass(std::string const& str):str(str){} std::string & getString(){return str;} void print() const{std::cout<<str<<std::endl;} private: std::string str; };
pour laquelle le code suivant sera tout à fait valide
Code:

1 2 3 4 5 6 7 8 int main() { MyClass c("salut"); c.print(); // affiche "sallut" c.getString() = "le monde"; c.print(); //affiche "le monde" return 0; }
Si tu veux que l'objet ne puisse pas être modifié, il faut alors prendre deux précautions:

signaler que la fonction s'engage à ne pas modifier la classe
signaler que la référence renvoyée ne peut pas être modifiée

Nous pourrions donc tout à fait envisager de modifier la classe en
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class MyClass { public: MyClass(std::string const& str):str(str){} // la version non constante std::string & getString(){return str;} // la version constante std::string const & getConstantString() const {return str;} void print() const{std::cout<<str<<std::endl;} private: std::string str; };
ce qui nous mettrait dans la situation suivante:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 int main() { MyClass noConstant("salut"); // un objet non constant MyClass const constant("Le monde"); // et un objet constant noConstant.getString(); // accepté, noConstant n'est pas constant noConstant.getConstantString(); // accepté, nous rajoutons des // restictions constant.getString(); // refusé... getString n'est pas une fonction // constante constant.getConstantString(); // accepté, getConstantString est une // fonction constante return 0; }
En pratique, nous écririons plutôt la classe sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class MyClass { public: MyClass(std::string const& str):str(str){} // la version non constante std::string & getString(){return str;} // la version constante std::string const & getString() const {return str;} void print() const{std::cout<<str<<std::endl;} private: std::string str; };
et la sélection de la version correcte sera effectuée par le compilateur selon la situation dans laquelel la fonction est invoquée: la version non constante ne sera utilisée que si l'objet au départ duquel la fonction est invoquée n'est pas constant et que la chaine qui sert à la récupération est destinée à être modifiée.

Il y a enfin un dernier point à prendre en compte lorsque l'on utilise des références comme arguments, c'est le fait que seules les références constantes peuvent être initialisées avec des variables temporaires non nommées.

Ainsi, si nous avions deux fonctions proches de
Code:

1 2 3 4 5 6 7 8 void foo(std::string & str) { /* n'importe quoi modifiant ou non str */ } void bar(std::string const & str) { /* n'importe quoi mais sans modification de str */ }
nous serions dans la situation suivante:
Code:

1 2 3 4 5 6 7 8 9 int main() { foo("salut"); // refusé: il est interdit d'utiliser une variable // temporaire non nommée sur une référence non constante bar("salut"); // accepté: une variable temporaire non nommée est // acceptée lorsqu'elle est transmise sous la forme d'une // référence constante return 0; }
Maintenant que ce (long) rappel a été fait, revenons sur ton problème d'une fonctino template proche de
Code:

1 2 3 4 template <typename T> vois f(T& t) { }
La première chose que tu as à faire, c'est de te poser la question de savoir si f va modifier ou non l'objet qui lui sera passé...

Tu devrais avoir facilement ta réponse car tu es sensé savoir le but poursuivi par f ;)

Si ta fonction a pour but de modifier l'objet passé, tu n'aura pas énormément le choix:
Soit tu passe l'objet sous la forme d'une référence non constante, ce qui te permet d'utiliser les fonctions membres non constantes de l'objet et de répercuter les modifications apportées dans la variable d'origine
Soit tu passe l'objet sous la forme d'une référence constante, dont tu provoques la copie, et tu travailles sur la copie de l'objet (qui te permet d'utiliser les fonctions membres non constantes de l'objet), mais les modifications apportées ne seront pas répercutées sur la variable d'origine.

Si par contre, ta fonction ne dois pas modifier l'objet passé, il est logique que tu ne puisse utiliser que les fonctions membres qui... se sont engagées à ne pas modifier l'objet ;)

Si, enfin, tu viens à envisager le fait que les éventuelles modifications soient subordonnées à la constance de l'objet passé en paramètre, il semble cohérent de prévoir deux fonctions clairement différentes (au moins du point de vue du nom de la fonction), car il s'agit de fonctions dont les responsabilités sont clairement différentes ;)

19/03/2009, 14h40
MatRem

Je vais me répéter, mais j'ai l'impression que mon problème n'est pas clair... (je crois que Médinoc m'a compris :) )
Ou alors c'est moi qui n'ait pas compris où tu voulais en venir (a priori c'est juste un petit cours sur l'utilisation de const ? ).

Il faut prendre f comme une fonction générique au sens ou elle n'est pas consciente de la constance de l'instance t référencée (et elle n'est de toute façon pas concernée par le problème).

En fait les deux questions soulevées sont :
- comment éviter d'écrire les deux surcharges de f, quand cela n'est pas nécessaire (et il y a déjà 2 solutions);
- pourquoi le compilateur instancie la version f(T &) quand on lui passe un temporaire alors qu'il sait très bien que cette version de f n'est pas utilisable avec un temporaire.
19/03/2009, 15h02
koala01
Mais quand tu reprend le raisonnement que tu as suivi pour en arriver à décider de créer une fonction template f, tu remarques qu'il correspond à peu près à:
1. Je veux factoriser du code qui fournisse tel comportement ==>créons une fonction
2. Je veux que le code facotrisé fonctionne quel que soit le type de donnée fourni==> rendons la fonction template
Tu sais dés le départ si le comportement à factoriser va tenter de modifier ou non l'objet qui lui sera fourni en argument, vu que c'est pour factoriser ce comportement que tu as décidé de créer une fonction ;)

A partir de là, la décision est finalement toute simple: si le comportement ne doit pas modifier l'objet fourni en argument, prend toutes les précaution et déclares cet argument comme constant...

Cela te donnera l'assurance que toute tentative d'accès à une fonction membre ne s'étant pas engagée à ne pas modifier l'objet sera refusée et que, dans le cas où certaines fonctions membres ont la caractéristique d'avoir une version qui s'est engagée à ne pas modifier l'objet et une autre qui n'a pas pris cet engagement, ce sera la version ayant pris l'engagement qui sera utilisée ;)

Si, cela peut arriver, ce qu'il te faut c'est une fonction qui a pour but de modifier l'objet et une autre fonction qui a simplement pour but d'agir comme un "visiteur qui ne touche à rien", il te faut deux fonctions clairement différentes indiquant clairement l'objectif qu'elles suivent ;)
19/03/2009, 15h07
3DArchi

Citation:

Envoyé par koala01

Si, cela peut arriver, ce qu'il te faut c'est une fonction qui a pour but de modifier l'objet et une autre fonction qui a simplement pour but d'agir comme un "visiteur qui ne touche à rien", il te faut deux fonctions clairement différentes indiquant clairement l'objectif qu'elles suivent ;)

En gros, ce que j'avais essayé d'expliquer au début :(
19/03/2009, 15h21
nicroman
Je crois que tu te mélange les pinceaux....

Quand tu appelles:
Code:

1 2 f(int(0))
Le compilateur va chercher les fonctions "f" disponibles, avec comme parametre 'int' ou 'int&'... S'il en trouve plusieurs... il va râler...
S'il n'en trouve pas... il va essayer avec un const, genre: 'const int' ou 'const int&'...
S'il n'en trouve toujours pas... il va essayer avec une promotion de type.
Et à chaque cas, si il y a plusieurs choix, il va râler en demandant d'être plus explicite...

Dans ton cas... il trouve immédiatement une fonction qui match avec T=int:
Code:

1 2 3 4 5 6 7 template<typename T> void f(T & val) { std::cout << val << std::endl; } T = int
Donc il va s'arrêter là et utiliser (en remplacant T par int):
Code:

1 2 3 template<int> void f(int& val)
Puis il va râler en disant: hey ! moi je veux bien utiliser cette fonction, c'est la seule qui correspond d'ailleurs, mais je peux pas convertir l'objet temporaire int(0) en int& ! Ce sur quoi il a raison...

Maintenant, le problême du const... Tu as raison en disant:

Citation:

elle n'est pas consciente de la constance de l'instance t référencée

car c'est le compilateur qui en a conscience... Mais le raisonnement est faux: comme dit koala (grilled !) c'est la fonction appellée qui a conscience du 'constness' de ses paramètres (bref de ce qu'elle va en faire)... et ainsi, indiquer au compilateur quelle(s) fonction(s) il peut sélectionner...

En déclarant le template ci-dessus tu dis: J'ai une fonction f<T>() qui *va* modifier le parametre passé (voir même prendre une référence dessus) !
Et le compilateur te dis: ok moi je veux bien utiliser cette fonction mais c'est pas raisonnable avec une variable temporaire !
19/03/2009, 15h29
nicroman
Juste une addition par rapport à l'explication de koala:

Citation:

dans le cas où certaines fonctions membres ont la caractéristique d'avoir une version qui s'est engagée à ne pas modifier l'objet et une autre qui n'a pas pris cet engagement, ce sera la version ayant pris l'engagement qui sera utilisée

C'est pas tout à fait vrai... Le compilateur est assez bête...

void f(const int& v);
void f(int& v);

int a;
f(a) => va appeler f(int& v);
f(2) => va appeler f(const int& v);

Dans le cadre d'une fonction membre:
Code:

1 2 3 4 5 6 class A { void f(const int& v) const; void f(int& v); }
se traduit en:
Code:

1 2 3 void A__f(const A* _this, const int& v); void A__f(A* _this, int& v);
Ce qui revient au résultat:
A constant, v constant => f(const)const
A constant, v non constant => f(const)const
A non constant, v constant => f(const)const
A non constant, v non constant => f()
19/03/2009, 15h36
MatRem

Citation:

Envoyé par koala01

Tu sais dés le départ si le comportement à factoriser va tenter de modifier ou non l'objet qui lui sera fourni en argument, vu que c'est pour factoriser ce comportement que tu as décidé de créer une fonction

Et non justement ma fonction est encore plus générique, elle est aussi indépendant de la constance de son paramètre.

Mais de toute façon je ne me posais pas de question au niveau de la conception... même si c'est intéressant d'en discuter ;)
19/03/2009, 15h40
MatRem

Citation:

Envoyé par nicroman

En déclarant le template ci-dessus tu dis: J'ai une fonction f<T>() qui *va* modifier le parametre passé (voir même prendre une référence dessus) !
Et le compilateur te dis: ok moi je veux bien utiliser cette fonction mais c'est pas raisonnable avec une variable temporaire !

Tout à fait f<T> peut potentiellement appeller des fonctions de t qui n'ont pas de version const et dans ce cas je suis tout à fait d'accord que le compilateur râle.
Mais dans mon exemple on peut voir que f appelle des fonctions sur t qui dont les deux versions const et non const existe. Le code de f est donc tout à fait indépendant de la constance de t (encore une fois ;) ).

Citation:

Envoyé par nicorman

Donc il va s'arrêter là et utiliser (en remplacant T par int):

Et la question est : "pourquoi ?"

Pourquoi avec un temporaire essaye t il d'instancier cette fonction et non pas f(int const &), ça lui éviterai de râler ;).

Voir 40 message(s) de cette discussion en une page