Instanciation de fonction template et temporaire

Version imprimable

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 ;).

Citation:

Envoyé par nicroman

Maintenant, le problême du const... Tu as raison en disant:
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 !

C'est surtout que, lorsque tu invoque une fonction sous la forme de

Code:

f<int>(1);

la valeur 1 est transformée en variable temporaire non nommée (temporaire car elle n'existe que pour l'appel de f et non nommée car tu ne dispose nulle part ailleurs d'un identifiant permettant de récupérer la valeur).

Or, la norme est particulièrement claire là dessus: lorsqu'il s'agit de travailler avec des références, seules les références constantes peuvent être initialisée avec des variables temporaires non nommées...

Comme tu ne respectes pas les règles, le compilateur s'en plaint violemment ;)

Les possibilités dont on dispose sont
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 /* argument passé par valeur: il y a création d'une variable nommée t * qui est la copie de la variable passée en paramètre */ template< typename T> void f( T t) { } /* arguement passé par valeur constante: il y a création d'une variable * (rendue consttante pour l'occasion) nommée t * qui est la copie de la variable passée en paramètre */ template <typename T> void g(T const t) { } /* argument passé par référence constante: il n'y aura création * d'une variable temporaire non nommée que si le paramètre * passé n'est pas une variable du type adéquat à la base * t est un alias de la variable passée en paramètre (éventuellement * de la variable temporaire non nommée créée spécialement pour l'occasion) */ template <typename T> void h(T const & t) { } /* ne fonctionnera que lorsqu'on invoque la fonction en lui passant * une variable existante par ailleurs * t est un alias de la variable passée en paramètre */ template <typename T> void i(T & t) { }
et nous place face aux situations suivantes:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 int main() { f<int> (2); // ok, création d'une variable nommée t dans f int i = 3; f<int>(i); // ok: création d'uen varaible nommée t dans f qui est la // copie de i g<int>(2); // ok: création d'une variable (constante) nommée t dans g g<int>(i); // idem h<int>(2); // ok: création d'une variable temporaire non nommée // qui sera passée par référence constante sous le nom de t h<int>(i); // ok: passage d'une variable existante sous la forme // d'une référence constante i<int>(2); // refusé: seule les références constantes peuvent accepter // les variables temporaires non nommées i<int>(i); // par contre, on peut passer n'importe quelle variable // existante sous la forme d'une référence }
Mais pour en revenir au choix de passer l'arguement sous la forme d'une référence constante ou non constante...

Lorsque tu décide d'écrire ta fonction, la logique voudrait que tu aie déjà réfléchi à l'algorithme que tu va mettre en oeuvre au sein de cette fonction:

Tu *devrais* en effet avoir une idée aussi précise que possible des différentes étapes qui seront suivies par ta fonction afin de lui permettre de présenter le comportement souhaité...

Tu *devrais* donc normalement être en mesure de déterminer si l'objet qui sera passé en paramètre sera modifié ou non ;)

Or nous savons que nous ne risquons rien à faire passer "temporairement" (comprend: le temps que dure la fonction appelée) un objet qui n'est pas constant à la base pour un objet constant: tout ce que nous faisons, c'est restreindre les différentes interactions que nous pouvons envisager sur cet objet ;)

D'un autre coté, nous savons aussi que, si nous décidons de permettre la modification de l'objet, il faut que notre objet soit à la base déclaré comme non constant: si l'objet est déclaré à la base constant, nous n'en attendons pas moins de la part du compilateur que le fait de nous signaler que nous allons tenter de modifier un objet qui ne peut normalement pas l'être ;)

C'est la raison pour laquelle le principe de const correctness t'incite, chaque fois qu'une fonction ne doit pas modifier un objet passé en argument, à indiquer à cette fonction de considérer "temporairement" (comprend: le temps que dure l'exécution de la fonction) l'argument passé "comme s'il était destiné à ne pas être modifié"...

19/03/2009, 16h18
MatRem

Citation:

Envoyé par koala1

Tu *devrais* donc normalement être en mesure de déterminer si l'objet qui sera passé en paramètre sera modifié ou non

Pkoi je ne peux pas avoir une fonction indépendante de la constance de t :pleure: (personnellement ça me sert vraiment ce genre de concept).
Si vraiment cela te dérange disons que c'est une hypothèse de travail "f est une fonction indépendante de la constance de t" :P

Citation:

Envoyé par Koala1

Or, la norme est particulièrement claire là dessus: lorsqu'il s'agit de travailler avec des références, seules les références constantes peuvent être initialisée avec des variables temporaires non nommées...

Oui c'est tout à fait juste, et donc pourquoi (ce n'est pas moi qui essaye d'instancier la fonction template f(T &)) le compilateur "ne respecte pas la règle" et essaye d'instancier cette fonction qui selon le standard ne peut pas prendre un temporaire?

ps : dans ton exemple tu forces T = int donc tu ne laisses pas grand choix au compilateur.
19/03/2009, 16h30
koala01
Citation:

Envoyé par MatRem

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

MAis lorsque tu décide qu'une fonction doit présenter un comportement, c'est que tu as déjà déterminé le comportement à implémenter... sinon, tu n'a aucune raison d'écrire une fonction qui ne fait rien ;)

Citation:

Envoyé par MatRem

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 ;).

Parce que le "cv-qualifier" fait partie de la définition de type...

Lorque tu indique que la forme canonique d'une déclaration de variable va prendre la forme de

Code:

<type_identifier> nom_variable;

<type_identifier> correspond à:
- type_name (int, char, MaClass,...) +
- cv_qualifier (const, volatile... defaut: volatile) +
- memory_access( (rien), *, &, *&, défaut: rien)
ce qui fait que le type int est différent du type int const...

Lorsque tu généralilse une fonction sous la forme de
template< typename T>

Code:

void foo( T /*& */ t);

tu indiques au compilateur que l'objet de type T doit etre non constant.

Or la "conversion" d'un objet constant en un objet non constant doit être explicite (par utilisation de const_cast ou par création d'une copie de l'objet).

Par contre, lorsque tu généralise une autre fonction sous la forme de
template<typename T>

Code:

void bar( T const /* & */ t);

tu dis explicitement que t doit être constant, et la conversion d'un objet à la base non constant en un objet constant peut se faire de manière implicite (sans que tu ne précise qu'il faille effectuer la conversion)...

C'est pour cela que, si tu déclares plutôt foo que bar, le compilateur, en "exécutant bête et méchant" ne "pensera pas" à implémenter une version constante de la fonction ;)
19/03/2009, 16h35
MatRem
Citation:

Envoyé par koala1

tu indiques au compilateur que l'objet de type T doit etre non constant.

alors pourquoi dans ce cas le compilateur génère la version f(T const &) :
Code:

1 2 3 4 5 6 7 8 9 10 template<typename T> void f(T & t) { } int main() { int const i; f(i); }
ps : dans ce cas T = int const
19/03/2009, 17h04
koala01
Citation:

Envoyé par MatRem

Pkoi je ne peux pas avoir une fonction indépendante de la constance de t :pleure: (personnellement ça me sert vraiment ce genre de concept).
Si vraiment cela te dérange disons que c'est une hypothèse de travail "f est une fonction indépendante de la constance de t" :P

Mais quand, dans ton EDI, tu va ouvrir un fichier (hpp) et commencer à écrire
Code:

1 2 3 4 5 template <typename T> void foo( T /* & */ t) { //ici, tu sais le comportement que tu dois implémenter pour ta fonction }
tu sais ce que la fonction va devoir faire, et si elle va devoir modifier t ou non...

Autrement, tu ne commencerais même pas à implémenter la fonction en question...

Ou, du moins, tu devrais avoir une idée suffisamment claire de ce qui sera fait pour pouvoir déterminer s'il y aura modification ou non de l'objet passé en paramètre ;)

Dés lors, pourquoi ne pas respecter le principe simple qui consiste à passer un objet constant s'il ne doit pas être modifié :question: cela te facilitera la vie lors de l'utilisation de la fonction ;)

Citation:

Oui c'est tout à fait juste, et donc pourquoi (ce n'est pas moi qui essaye d'instancier la fonction template f(T &)) le compilateur "ne respecte pas la règle" et essaye d'instancier cette fonction qui selon le standard ne peut pas prendre un temporaire?

ps : dans ton exemple tu forces T = int donc tu ne laisses pas grand choix au compilateur.

Les réponses se sont croisées, mais tout vient du fait que le "cv-qualifier" fait partie de "l'identificateur de type", et donc qu'un objet de type non constant est différent d'un objet de type identique mais constant (même si on peut convertir implicitement un objet non constant en objet constant)

Ceci dit, que tu forces T = int ou non, le problème reste le même (par contre, tu as peut etre justement l'avantage de clairement indiquer le type qui doit être utilisé ;))
Citation:
Envoyé par MatRem

alors pourquoi dans ce cas le compilateur génère la version f(T const &) :

Code:

1 2 3 4 5 6 7 8 9 10 template<typename T> void f(T & t) { } int main() { int const i; f(i); }

ps : dans ce cas T = int const
Parce que le compilateur est par nature paresseux et va prendre la première version qui lui semble valide...

Dans ton exemple, tu indiques explicitement que i est de type int const... et il va donc "logiquement" utiliser ce type particulier.

Par contre, si tu appelles f sous la forme de f(153); le type le plus simple permettant d'instancier l'appel sera, en dehors de toute indication de ta part, le type... int et non le type int const :P

Ce sera donc vers le type int que le compilateur se tournera naturellement... Et c'est là que les problèmes commenceront...

En effet, après avoir implémenté la version prenant un int &, du fait même de son mode de fonctionnement, il ne fera plus marche arrière (pour l'appel envisagé) et il se rendra compte que cela revient à lui demander de créer une variable temporaire non nommée... ce qu'il ne peut pas faire si c'est pour l'utiliser sous la forme d'une référence non constante...

Citation:

Envoyé par Koala1

tu sais ce que la fonction va devoir faire, et si elle va devoir modifier t ou non...

Voilà un exemple un peu plus "concret" pour essayer de te faire partager mon intérêt pour le concept de fonction non concernée par la constance de leur paramètre :P :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 template<typename Q, typename F, typename P> typename P::Type ForEachChild(Q & quadtree, F & functer, P & policy) { assert(!quadtree.IsLeaf()); for (size_t i = 0; policy.Continue() && i < MAX_CHILD; ++i) { policy.Call( tools::const_ref( boost::bind<typename P::Type>( boost::ref(functer), boost::ref(quadtree.GetChild(Index(i))) ) ) ); } return policy.Result(); }
Cette exemple ne peut pas fonctionner avec un functer temporaire (entre autre), hors je ne sais pas du tout dans cette fonction si je vais devoir modifier mon functer.
En fait c'est la policy qui dans Call appellera l'opérateur parenthèse du functer.

C'est à l'utilisateur de la fonction ForEachChild de gérer la constance => si l'utilisateur passe un functer const, il doit définir un opérateur parenthèse const dans son functer.

Citation:

Envoyé par Koala1

Par contre, si tu appelles f sous la forme de f(153); le type le plus simple permettant d'instancier l'appel sera, en dehors de toute indication de ta part, le type... int et non le type int const

Quel est l'intérêt pour le compilateur d'avoir ce comportement,
Puisque'à la compilation il sait :
- qu'il a affaire a un temporaire;
- que les temporaire ne peuvent passer par référence que vers un type const;

Citation:
Envoyé par MatRem
Voilà un exemple un peu plus "concret" pour essayer de te faire partager mon intérêt pour le concept de fonction non concernée par la constance de leur paramètre :P :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 template<typename Q, typename F, typename P> typename P::Type ForEachChild(Q & quadtree, F & functer, P & policy) { assert(!quadtree.IsLeaf()); for (size_t i = 0; policy.Continue() && i < MAX_CHILD; ++i) { policy.Call( tools::const_ref( boost::bind<typename P::Type>( boost::ref(functer), boost::ref(quadtree.GetChild(Index(i))) ) ) ); } return policy.Result(); }
Cette exemple ne peut pas fonctionner avec un functer temporaire (entre autre), hors je ne sais pas du tout dans cette fonction si je vais devoir modifier mon functer.
En fait c'est la policy qui dans Call appellera l'opérateur parenthèse du functer.
Ben, en général le functeur est passé par valeur et il est constant. Ce sont éventuellement les paramètres qu'ils prend qui seront l'objet de la modification.
Je continue de partager l'avis de Koala : si tu dois avoir une version non const, alors il faut la différencier de la version const.

Citation:
Envoyé par MatRem
Voilà un exemple un peu plus "concret" pour essayer de te faire partager mon intérêt pour le concept de fonction non concernée par la constance de leur paramètre :P :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 template<typename Q, typename F, typename P> typename P::Type ForEachChild(Q & quadtree, F & functer, P & policy) { assert(!quadtree.IsLeaf()); for (size_t i = 0; policy.Continue() && i < MAX_CHILD; ++i) { policy.Call( tools::const_ref( boost::bind<typename P::Type>( boost::ref(functer), boost::ref(quadtree.GetChild(Index(i))) ) ) ); } return policy.Result(); }
Cette exemple ne peut pas fonctionner avec un functer temporaire (entre autre), hors je ne sais pas du tout dans cette fonction si je vais devoir modifier mon functer.
En fait c'est la policy qui dans Call appellera l'opérateur parenthèse du functer.

C'est à l'utilisateur de la fonction ForEachChild de gérer la constance => si l'utilisateur passe un functer const, il doit définir un opérateur parenthèse const dans son functer.
Je vois mieux quel est ton problème...
Ton foncteur ne devra pas être modifé ;)

Au mieux, le foncteur doit modifier ou non l'objet qui lui est passé en paramètre ;)

Mais cela implique que c'est ta politique qui doit permettre de "mettre en évidence" si ton foncteur modifiera ou non l'objet passé en paramètre ;)

C'est à dire qu'il faut veiller à fournir une spécialisation de ta politique de manière à ce qu'elle considère les objets constants différemment des objets non constant ;)

Typiquement, la solution est donnée par les différentes implémentations des (policy / call) traits que l'on trouve dans boost et / ou dans la STL:
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 49 50 51 52 53 54 55 56 /* la définition "de base" (non constante, non référence, ni rien) */ template <typename T> struct call_traits { public: typedef T value_type; typedef T& reference; typedef const T& const_reference; /* simplifé à l'extrème ;) */ typedef T param_type; }; /* spécialisation pour les références */ template <typename T> struct call_traits<T&> { typedef T& value_type; typedef T& reference; typedef const T& const_reference; typedef T& param_type; }; /* spécialisation pour les références constantes */ template <typename T> struct call_traits<T&const> { typedef T& value_type; typedef T& reference; typedef const T& const_reference; typedef T const & param_type; }; /* specialisation pour les références explicitement volatiles */ template <typename T> struct call_traits<T&volatile> { typedef T& value_type; typedef T& reference; typedef const T& const_reference; typedef T& param_type; }; /* spécialisation pour les référence volatiles constantes (si si, ca arrive :D)*/ template <typename T> struct call_traits<T&const volatile> { typedef T& value_type; typedef T& reference; typedef const T& const_reference; typedef T& param_type; }; /* spécialistation pour les pointeurs */ template <typename T> struct call_traits< T * > { typedef T * value_type; typedef T * & reference; typedef T * const param_type; };
et tu spécialise ta fonction sur base de cette politique
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 /* la fonction "de base" */ template<typename Q, typename F, typename P> typename P::Type ForEachChild(Q & quadtree, F & functer, P & policy) { assert(!quadtree.IsLeaf()); for (size_t i = 0; policy.Continue() && i < MAX_CHILD; ++i) { policy.Call( tools::const_ref( boost::bind<typename P::Type>( boost::ref(functer), boost::ref(quadtree.GetChild(Index(i))) ) ) ); } return policy.Result(); } /* et les spécialisations */ template<typename Q, typename F> typename P<Q, F, call_traits< const T> >::Type ForEachChild<Q, F, call_traits< const T> >(Q & quadtree, F & functer, call_traits<const T> & P){ /* à toi de jouer :D */ }
Citation:

Quel est l'intérêt pour le compilateur d'avoir ce comportement,
Puisque'à la compilation il sait :
- qu'il a affaire a un temporaire;
- que les temporaire ne peuvent passer par référence que vers un type const;

Je n'ai pas dit que cela avait le moindre intérêt (car cela n'en a strictement aucun), j'ai dit que, du fait de son mode de fonctionnement et de sa "paresse naturelle", c'est malheureusement comme cela qu'il fonctionne...

Je ne suis pas assez doué dans le fonctionnement même des compilateur pour t'en donner la raison précise, mais cette "incohérence" vient principalement du fait qu'ils fonctionnent en utilisant principalement des piles d'implémentations qui font qu'ils "perdent" en cours de route le fait qu'il devront manipuler une variable temporaire ;) (je crois d'ailleurs que cela a aussi à voir avec le fait qu'une seule conversion implicite est autorisée par la norme alors que l'appel sous la forme de f(152) en nécessiterait deux ou trois: de 152-->int, de int--> int const et de int const--> int const & )

19/03/2009, 20h32
MatRem

Citation:

Envoyé par Koala1

Ton foncteur ne devra pas être modifé

Pourquoi pas? En tout cas cette fonction ne modifie pas explicitement l'état du foncteur, elle permet juste à l'utilisateur de passer un foncteur non const. Et le cas échéant suivant la composition Quadtree/Functer/Policy ne pouvoir le modifier, soit parceque son opérateur parenthèse n'est pas const (parce qu'il modifie l'état interne de l'instance), soit parceque la policy modifie le functer.
C'est juste un niveau de liberté supplémentaire pour l'utilisateur de l'API.

Si j'avais voulu ne pas le permettre j'aurais : F const &.

D'ailleurs j'ai permis la même liberté pour le quadtree et la policy.

Citation:

Envoyé par Koala1

/* à toi de jouer :D */

Que ferait de plus ou de moins cette spécialisation ?...

Citation:

Envoyé par Koala1

ils fonctionnent en utilisant principalement des piles d'implémentations qui font qu'ils "perdent" en cours de route le fait qu'il devront manipuler une variable temporaire

Intéressant... donc a priori se serait lié à un problème technique au niveau du parseur?

J'aimerais bien approfondir ce point là, si quelqu'un peut m'en dire plus.
19/03/2009, 21h18
koala01

Citation:

Envoyé par MatRem

Intéressant... donc a priori se serait lié à un problème technique au niveau du parseur?

J'aimerais bien approfondir ce point là, si quelqu'un peut m'en dire plus.

Ne pars pas trop vite en guerre sur base de mes écrits ;)

Un problème technique au niveau du parser est une solution, mais une autre, bien plus vraisemblable, vient d'une restriction imposée par la norme quant aux différentes conversions et la manière dont elles sont envisageables ;)

N'oublie pas non plus le fait de transmettre une variable temporaire non nommée est l'exception par rapport à la règle générale d'appel d'une fonction: nous transmettons généralement une variable existant par ailleurs ;)

La règle selon laquelle une variable temporaire non nommée ne peut être utilisée que sur un objet constant (quand il s'agit de travailler avec une référence) vient de la constatation logique selon laquelle il est inutile (et dangeureux :question:) de permettre la modification d'une telle variable temporaire: les modifications apportées (et répercutées) sur la variable disparaissant "logiquement" en même temps que la variable, c'est à dire... lors de la sortie de la portée de la fonction appelée...

Il semble "logique" que, entre une règle générale et une exception, le compilateur fasse d'abord attention à la règle générale (toute variable transmise en argument existe par ailleurs), plutôt qu'à l'exception (mais, parfois, on peut utiliser une variable temporaire non nommée) ;)
20/03/2009, 02h01
koala01
Citation:

Envoyé par MatRem

Pourquoi pas? En tout cas cette fonction ne modifie pas explicitement l'état du foncteur, elle permet juste à l'utilisateur de passer un foncteur non const. Et le cas échéant suivant la composition Quadtree/Functer/Policy ne pouvoir le modifier, soit parceque son opérateur parenthèse n'est pas const (parce qu'il modifie l'état interne de l'instance), soit parceque la policy modifie le functer.
C'est juste un niveau de liberté supplémentaire pour l'utilisateur de l'API.

Si j'avais voulu ne pas le permettre j'aurais : F const &.

D'ailleurs j'ai permis la même liberté pour le quadtree et la policy.

Que ferait de plus ou de moins cette spécialisation ?...

La spécialisation agirait principalement sur le type de retour envisagé, selon quatre axes principaux (en excluant l'axe des pointeurs):
- Le type lui-même (call_traits::value_type) pour les foncteurs non constants renvoyant une instance
- le type lui-même mais déclaré constant (call_traits::value_type const) pour les foncteurs constants renvoyant une instance (constante)
- une référence non constante (call_traits::reference) pour les foncteurs non constants renvoyant une référence non constante
- une référence constante (call_traits::const_reference) pour les foncteurs constant renvoyant une... référence constante
Cela se traduirait principalement par le fait que le retour de fonction est susceptible de changer selon le cas, et par le fait d'utiliser, dans certains cas boost::cref au lieu de boost::ref ;)