Hi,
 
J'avais déjà vu que le mot clef template pouvait être utilisé ailleurs que devant le nom d'une classe ou le nom d'une fonction ou pour faire une instanciation explicite.. mais je m'en rappel plus lol.
Un peu comme avec le mot clef typename que l'on mets aussi devant un membre donné pour que le compilateur sache que c'est un type.
 
Quelqu'un voit ?
 
Merci.

appel d'une methode template d'un objet tempalte:
 
MonObjet<T> m;
m::templte foo<U>();
 

http://forum.hardware.fr/hfr/Progr [...] 1218_1.htm

c'est ça merci bien

mais dans ton exemple, si on supprime les  .template et ->template le code compile quand même   , Y a des cas ou  
sans .template, la compilation passe pas il me semble

De memoire, il n'est autorise que quand il est obligatoire en C++03.  De memoire toujours, en C++0X on relachera un peu cette contrainte.

Il y a (eu?) des compilateurs n'implementant par la recherche de noms en deux temps qui ignoraient purement et simplement ces indications aux endroits ou elles etaient autorisees grammaticalement sans verifier qu'elle etait autorisee semantiquement.  Et chez eux, les virer compile toujours.

Exemple complet et compilable (mais plutot stupide) ou ce devrait etre obligatoire (ce l'est pour gcc 4.3.3 et pour comeau http://www.comeaucomputing.com/tryitout/)

ok donc c'est juste sous visual 2008 où le comportement est différent,  il ne requière pas l'utilistion du .template

pas seulement visual C++, il vaut mieux rester 100% standard même si ton compilo est + tolérant. Sur certains compilos, 'typename' devant 'T::result' est également optionnel, mais il vaut mieux le mettre qd même.
 
Sinon, template est aussi utilisé pour indiquer qu'un paramètre d'un template est un autre template, mais je n'en ai jamais vu d'utilisation concrète.
http://www.informit.com/articles/article.aspx?p=376878

ca servait avant MPL pour emuler des meta-fonctions d'ordre supérieur.
Le protocole apply l'a rendu obsolete.
 
Sinon t'as toujours le vieux :
 

oui mais bon ça c'est l'exemple scolaire classique, qui est donné sous une autre forme dans le lien ci dessus, mais en pratique je ne vois pas trop d'utilité concrète pour cette fonctionnalité, même si j'apprécie qu'il l'aie fournie, "power to the compiler"

En gros ca servait avant qu'on ai un vrai systeme de meta-fonction polymorphique.
Le truc ci-dessus s'ecrit desormais :

Depusi MPL, les template tempalte ne servent que dans quelques cas foireux.

pas mal ce mpl::apply, je ne connaissais pas !
par contre le token _, bof, risque de conflit avec gettext...

pardon :
 
typedef make_container< vector<mpl::_>,float>::type
 
_ et ses freres (_1,_2,_3,_4,_5 et _6) sont juste des lambda-placeholder

ben _1, _2 ok je connaissais avec boost::bind, mais _, c'est une macro de gettext, surement + ancienne que boost::mpl, donc ça me fait peur

 
C'est une macro fonction, donc tant que c'est pas suivit par une parenthèse il n'y a pas clash.  
 
Mais c'est quand même jouer aux limites.

ouais enfin v_v paye ta macro aussi :E
Pour info, j'utilsie le meme token pour simuler le : de matlab dans ma bibliothèque de calcul numérique, ca n'a jamais clashé avec quoi que ce soit :E

 
Ca marche ça ? Et bien j'ai appris un truc, merci ! Je pensais que les macros étaient toutes remplacées par le préprocesseur, macro-fonction ou pas. Dans ce cas pas de conflit entre _() de gettext et mpl::_ de boost .

 
Oui.   Il faut faire simplement attention à ne pas inclure des entêtes standards parce qu'alors on passe dans le comportement indéfini.
 
Et à ne pas avoir des collègues violents naturellement.