[template] passer un argument par valeur ou en const &

Bonjour.

J'ai récemment écrit la classe de wrapper simple suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template <class Wrapped> class Wrapper : public Wrapped { public: Wrapper():Wrapped(){} template <class T> Wrapper(T t):Wrapped(t) { char u;//juste pour déclencher un warning. } };

---

j'essaye ensuite d'exécuter ce code:

Code:

---

1 2 3 4 5 6 7 8 9

int main() { std::string s; char f[32]="dummy" Wrapper<std::string> u(s); Wrapper<std::string> v("foo"); Wrapper<std::string> w(f); }

---

quand je regarde le message du compilo, j'ai:

Citation:

---

Envoyé par gcc 4.4.1

-------------- Build: Debug in Boost_Serialize_Test ---------------

Compiling: main.cpp
/.../main.cpp: In constructor ‘Wrapper<Wrapped>::Wrapper(T) [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Wrapped = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]’:
/.../main.cpp:103: instantiated from here
/.../main.cpp:39: warning: unused variable ‘u’
/.../main.cpp: In constructor ‘Wrapper<Wrapped>::Wrapper(T) [with T = const char*, Wrapped = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]’:
/.../main.cpp:104: instantiated from here
/.../main.cpp:39: warning: unused variable ‘u’
/.../main.cpp: In constructor ‘Wrapper<Wrapped>::Wrapper(T) [with T = char*, Wrapped = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]’:
/.../main.cpp:105: instantiated from here
/.../main.cpp:39: warning: unused variable ‘u’
Linking console executable: bin/Debug/Boost_Serialize_Test
Output size is 252,76 KB
Process terminated with status 0 (0 minutes, 7 seconds)
0 errors, 4 warnings

---

La partie en rouge montre que le constructeur prend pour string un passage par valeur... or j'aimerais bien avoir, dans ce cas, un passage par référence de type const std::string &...

il faudrait pour cela spécialiser le template, je suppose sur un critère de taille du parametre wrapped. Je me souviens avoir déjà vu ce genre de bout de code sur le forum, mais impossible de le retrouver :( ... si vous savez ou le trouver ou comment faire , merci d'avance ;)

Code:

---

Wrapper(T t):Wrapped(t)

---

:aie::aie:

Ne serait-ce pas plutôt ça :

Code:

---

Wrapper(const T& t):Wrapped(t)

---

Si tu veux systématiquement un const T&, il suffit de demander.

Sinon, il faut une classe de traits, un truc de ce genre:

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

template< class T, bool IsBig > class Param2 { public: typedef T type; };   //Note: je ne me souviens plus de la syntaxe pour les spécialisations partielles de classe template template< class T > class Param2< T, true > { public: typedef T const &type; };   template< class T > class Param { public: typedef typename Param2< T, (sizeof(T)>sizeof(long long))>::type type; };     template< class T > void UneFonctionTemplate(typename Param<T>::type toto) { //Blabla }

---

ou boost::call_traits<T>::param_type ... .

@Medinoc : c'est bien ça la syntaxe pour la spécialisation partielle.

Citation:

---

Envoyé par Médinoc

Sinon, il faut une classe de traits, un truc de ce genre:

---

c'est effectivement ce qu'il me fallait. la spécialisation est bonne et marche bien.... mais je ne peux pas utiliser le type: je ne comprend pas:

Code:

---

1 2 3 4 5 6 7 8

template< class T > class Param { public: typedef typename Param2< T, (sizeof(T)>sizeof(long long))>::type type; //error: type ‘Param2<T, (sizeof (T) > 8u)>’ is not derived from type ‘Param<T>’| ///error: expected ‘;’ before ‘type’| };

---

je vais voir pour boost .... :(

Edit: quelqu'un pourrai-til tester chez lui pour voir si ça vient de moi ?
merci

je viens de tester avec boost j'ai exactement le même problème :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <boost/call_traits.hpp> #include <string> template <class Wrapped> class Wrapper : public Wrapped { public: Wrapper():Wrapped(){}   template <class T> Wrapper( boost::call_traits<T>::param_type t) //error: expected ‘)’ before ‘t’ :Wrapped(t) { char u; } };     int main() { Wrapper<std::string> * x=new Wrapper<std::string>("blabla"); return 0; }

---

avec comme erreur:

Citation:

---

Envoyé par gcc

-------------- Build: Debug in Boost_Serialize_Test ---------------

Compiling: main.cpp
/.../main.cpp:41: error: expected ‘)’ before ‘t’
/.../main.cpp: In function ‘int main()’:
/.../main.cpp:101: error: no matching function for call to ‘Wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::Wrapper(const char [24])’
/.../main.cpp:38: note: candidates are: Wrapper<Wrapped>::Wrapper() [with Wrapped = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]
/.../main.cpp:36: note: Wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::Wrapper(const Wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)
/.../main.cpp:101: warning: unused variable ‘x’
Process terminated with status 1 (0 minutes, 1 seconds)
2 errors, 1 warnings

---

(note: les numéros de ligne ne sont pas les bons, car j'ai retiré des commentaires).

quelqu'un a une idée :( ?

merci

Truc très con, mais qui m'a souvent dépanné dans le passé, c'est d'utiliser l'option "/P" de VS pour avoir le résultat du pré-processing de l'unité de compilation.
C'est permet de voir des remplacements via MACRO ou des ; manquant en fin de fichier d'include, etc...

Donc quand je comprends rien, je fais cette astuce pour voir si c'est moi ou une connerie dans un fichier d'en-tête connu ni d'Eve ni des dents. :aie:

heu...contrairement à visual gcc n'inclut rien de base normalement (a part les librairies iso, mais pas les headers), enfin je vais essayer


Edit: c'est pas les options de compilation : même sur codepad, j'ai ça... :( personne n'a une idée sur la nature de l'erreur ?

C'est surtout pour le résultat du traitement des macros par le préprocesseur.

typename boost::call_traits<T>::param_type ?

faq : typename.


edit : wow grillé de quelques secondes

Pourquoi introduit un type T pour ton ctor. Il devrait prendre un type Wrapped en paramètre non ? Il manque un typename associé au boost::call_traits<Wrapped> (voir faq, ou la doc de boost::call_traits).

Ça devrait donner un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template <class Wrapped> class Wrapper : public Wrapped { public: Wrapper():Wrapped(){}   Wrapper(typename boost::call_traits<Wrapped>::param_type t) :Wrapped(t) { char u; } };

---

De toute façon, un type T n'est probablement aps convertible en wrapped et si il l'est le compilateur va faire ça comme un grand.

Side note : c'est vraiment légal de dériver de std::string (destructeur non virtuel, etc ...) ?

edit : grillé deux fois :D

Citation:

---

Envoyé par Jean-Marc.Bourguet

typename boost::call_traits<T>::param_type ?

---

>< le pire c'est que c'est pas la première fois que je le rencontre celui-là :mur:

Citation:

---

Envoyé par zul

Pourquoi introduit un type T pour ton ctor. Il devrait prendre un type Wrapped en paramètre non ?

---

non car string ne prend pas que des strings en paramètres pour sa construction Il manque un typename associé au boost::call_traits<Wrapped> (voir faq, ou la doc de boost::call_traits).

Citation:

---

Envoyé par zul

[...] et si il l'est le compilateur va faire ça comme un grand.

---

c'est à dire ? :?


par contre, modifié, le code donne

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <boost/call_traits.hpp> #include <string> template <class Wrapped> class Wrapper : public Wrapped { public: Wrapper():Wrapped(){}   template <class T> Wrapper(typename boost::call_traits<T>::param_type t) //error: expected ‘)’ before ‘t’ :Wrapped(t) { char u; } };     int main() { Wrapper<std::string> * x=new Wrapper<std::string>("blabla"); return 0; }

---

mais là, le compilo est incapable de déterminer un constructeur:

Citation:

---

Envoyé par gcc

-------------- Build: Debug in Boost_Serialize_Test ---------------

Compiling: main.cpp
/.../main.cpp: In function ‘int main()’:
/.../main.cpp:101: error: no matching function for call to ‘Wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::Wrapper(const char [24])’
/.../main.cpp:38: note: candidates are: Wrapper<Wrapped>::Wrapper() [with Wrapped = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]
/.../main.cpp:36: note: Wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::Wrapper(const Wrapper<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)
Process terminated with status 1 (0 minutes, 1 seconds)
1 errors, 0 warnings

---

on a bien evidement l'équivalent sur codepad


Je ne sais pas si c'est dû à cette histoire de types primitifs, mais si c'ets le cas, ça m'embète :? ...
j'avais construit cette classe par-ce que boost::serialization n'acceptait pas les types primitifs -> retour à la case départ :aie:

quelqu'un a une idée ?

vous allez rire (ou pas ) :aie:

le problème ne vient en fait pas de la classe elle même mais du typename : en effet, si j'écris

Code:

---

1 2 3 4 5 6 7 8 9

template <class Wrapped> class Wrapper : public Wrapped { public: Wrapper():Wrapped(){} template <class T> Wrapper(T t):Wrapped(t) { } };

---

ça compile, mais on est confronté au problème initial d'absence de const &...

cependant, en tournant autour du code, j'ai écrit :

Code:

---

1 2 3 4 5 6 7 8 9

template <class Wrapped> class Wrapper : public Wrapped { public: Wrapper():Wrapped(){} template <class T> Wrapper( typename T t):Wrapped(t) { } };

---

et là, on retrouve la même erreur que juste au dessus, c'est à dire qu'il ne trouve pas de constructeur approprié: en effet, typename impose que ce soit un type de type class-name mais si on ne l'utilise pas le compilo ne sait pas que c'est un type, mais si on l'utilise, il croit que c'est un class-name mais si on l'utilise pas...

Code:

---

segmentation fault

---

:fou:

bref, un peu casse-tête. Le problème revient d'ailleurs à un problème de typage non générique et autre comme dans cette discussion (promis, c'est une coincidence)...

Bon, je vais rebooter et je vous laisse recuser (récursiver ? récursiviter ?) sur ce problème :aie:

bonne nuit ;)

On n'hérite pas de std::string publiquement, pas de destructeur virtuel.

Sinon pour les typename, j'ai pas de compilateur sous la main pour tester (et pas assez d'expérience pour trouver la solution comme ca à ce genre de code). Mais je ne vois pas ce que vient faire là la différence entre classe-name et type (et encore moins le rapport entre ce problème et ta volonté d'hériter d'autre chose que d'une classe !).

Un classe-name c'est juste ce qui représente le nom d'une classe, un type caractérise la facon dont les données doivent être traitées (pas de meilleur définition sur le coup :s). Et typename et juste une indication au compilateur qui lui signifie que ce qui suit est bel et bien un type (il ne peut en être sûre à cause du paramètre template), donc dans ton avant dernier code le typename sert à rien, le compilateur sait que T est un type.

Citation:

---

Envoyé par méphistopheles

j'avais construit cette classe par-ce que boost::serialization n'acceptait pas les types primitifs

---

Bonsoir,
Je ne vois pas bien ce que vous voulez dire. En quoi boost::serialization n'accepte-t-il pas les type primitifs?

Citation:

---

Envoyé par Flob90

On n'hérite pas de std::string publiquement, pas de destructeur virtuel.

---

pas vraiment un problème dans mon cas puique je n'ai pas d'autre objets à détruire...

Citation:

---

Envoyé par Flob90

Un classe-name c'est juste ce qui représente le nom d'une classe, un type caractérise la facon dont les données doivent être traitées (pas de meilleur définition sur le coup :s). Et typename et juste une indication au compilateur qui lui signifie que ce qui suit est bel et bien un type (il ne peut en être sûre à cause du paramètre template), donc dans ton avant dernier code le typename sert à rien, le compilateur sait que T est un type.

---

je veux bien te croire, je ne fais que constater... d'aprés l'exemple ci-dessus, ils semble que le typename aie un effet réel alors qu'il ne dervrait juste "servir à rien" ... ce qui est relativement curieux.
Pour le compilateur, il y a toujours codepad :).

Citation:

---

Envoyé par Nogane

Bonsoir,
Je ne vois pas bien ce que vous voulez dire. En quoi boost::serialization n'accepte-t-il pas les type primitifs?

---

je l'explique dans ce sujet . c'est un tout petit point de la grosse doc de serialization.

As-tu essayé la variante que j'ai proposé ?
Comme je le disais, le type T accepté par le template sont les types directement convertibles vers Wrapped. Mais si ils sont directement convertibles par Wrapped, le compilateur va appliquer la conversion automatiquement (voir chapitre 4 de la norme sur les standards + les constructeurs non explicites).

Même si tu n'a pas d'autres champs, ça reste il me semble un UB.

Sinon, pourquoi veux tu absolument utiliser des pointeurs nus vers std::string ? Quel est l'intérêt ?

Citation:

---

Envoyé par zul

As-tu essayé la variante que j'ai proposé ?
Comme je le disais, le type T accepté par le template sont les types directement convertibles vers Wrapped. Mais si ils sont directement convertibles par Wrapped, le compilateur va appliquer la conversion automatiquement (voir chapitre 4 de la norme sur les standards + les constructeurs non explicites).

---

à vrai dire je n'ai pas bien compris de quoi il s'agissait (si c'est une optimisation post résolution des templates ou pré résolution des templates) etc... si celle-ci se fait avant, le premier post du sujet prouve que ça ne marche pas puisque le type de l'argument est un std::string et non un const std::string &... :?

Citation:

---

Envoyé par rappel: gcc a dit

Compiling: main.cpp
/.../main.cpp: In constructor ‘Wrapper<Wrapped>::Wrapper(T) [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Wrapped = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]’:[...] warning: unused variable ‘u’

---

Citation:

---

Envoyé par zul

Même si tu n'a pas d'autres champs, ça reste il me semble un UB.

---

UB ? :weird:

Citation:

---

Envoyé par zul

Sinon, pourquoi veux tu absolument utiliser des pointeurs nus vers std::string ? Quel est l'intérêt ?

---

ben à la base je voulais utiliser des pointeurs sur n'importequoi. or ça marchait pas avec des string. j'ai donc voulu faire un wrapper généric pour résoudre le problème des pointeurs... c'aurait été facile si je l'avais fait juste pour les string (y'a pas 50000 constructeurs à surcharger) mais comme je suis un entété, je veux pas m'abaisser à faire du cas par cas (alors que je ne travaille que sur un cas, je sais, très logique, mais bon, il faut bien résoudre un problème avant d'attaquer les autres :aie:).

Si tu ne veux pas essayer / tester / comprendre, on ne peut rien faire pour toi.
En l'occurence, ton constructeur attend ici un const std::string&, et le compilateur va essayer de trouver une conversion entre un const char[] et un const std::string& (ça tombe bien y'en a un).

UB = Undefined Behaviour (Comportement Indéfini)

Et c'est définitivement une mauvaise raison :D

Citation:

---

Envoyé par zul

Si tu ne veux pas essayer / tester / comprendre, on ne peut rien faire pour toi.

---

j'ai testé! que veux tu que je modifie par rapport à mon premier test pour tester tes optimisations compilateurs ?

Citation:

---

Envoyé par zul

En l'occurence, ton constructeur attend ici un const std::string&, et le compilateur va essayer de trouver une conversion entre un const char[] et un const std::string& (ça tombe bien y'en a un).

---

Dans quel exemple ?
Dans celui que je viens de donner, je fournis un std::string et le compilo les passe en std string au lieu d'un const std::string &... Dans l'autre ça ne compile pas je ne vois pas de quoi tu parle. Dans le cas ou tu veux me faire faire une modification sur mon code auparavant (pour tester les optimisations compilateur), pourrais-tu être plus clair sur ce qu'il faut tester/modifier/essayer/comprendre ? Je dois être idiot, mais je n'arrive pas à savoir de quoi tu parle.

Citation:

---

Envoyé par zul

Et c'est définitivement une mauvaise raison :D

---

Une fois de plus, de quoi parle tu ? quand je lis ton post, j'ai l'impression d'avoir perdu la moitié de mon cerveau cette nuit et de ne pas être capable de suivre un propos :(

Le code que j'ai indiqué dans le post #12 ? (qui utilise un le call_traits correctement, mais sur Wrapped).

Et je ne vois pas le rapport avec les optimisations compilos (à par qu'avec le RVO, passer une std::string ou une const std::string& dans ce contexte précis, ça doit pas changer grand chose).

Les mauvaises raisons sont par rapport à l'utilisation de pointeur sur std::string dans ce contexte (et je ne parle pas de pointer sur un objet existant, mais d'allouer une string sur le tas avec un new, d'utiliser des pointeurs nus et de gérer (probablement mal) leur durée de vie de cette façon)). Après tu en fais bien ce que tu veux, je suis juste curieux de savoir pourquoi tu veux faire ce genre de "choses" ?

Citation:

---

Envoyé par zul

Le code que j'ai indiqué dans le post #12 ? (qui utilise un le call_traits correctement, mais sur Wrapped).

---

désolé :( je l'avait complétement oblitéré, je me rappelais qu'il était pareil en fait donc déjà compilé. toutes mes excuses. ça marche bien :oops:
Le reste de mes propos incohérent vient de cette mésentente (merci de m'avoir remis le cerveau en place. faut juste que je change de mémoire)

Citation:

---

Envoyé par zul

Les mauvaises raisons sont par rapport à l'utilisation de pointeur sur std::string dans ce contexte (et je ne parle pas de pointer sur un objet existant, mais d'allouer une string sur le tas avec un new, d'utiliser des pointeurs nus et de gérer (probablement mal) leur durée de vie de cette façon)). Après tu en fais bien ce que tu veux, je suis juste curieux de savoir pourquoi tu veux faire ce genre de "choses" ?

---

en fait, je compte pointer sur un string existant car j'ai en gros un tableau qui est lié à un autre (plus petit) genre attribut, l'idée étant de serializer les deux. (boost serialization tenant compte de l'unicité des pointeurs).j'aurais également pu utiliser des identifiant mais la seconde base à tendance à se réordonner(mais c'est une liste) donc j'ai préféré des pointeurs... peut être es-ce un mauvais choix et qu'une lut aurait eu de meilleurs résultats... :oops:

en tout cas, merci beaucoup, le problème est résolu :)

Pas de problème.

Citation:

---

Envoyé par méphistopheles

pas vraiment un problème dans mon cas puique je n'ai pas d'autre objets à détruire...

---

A part que ne détruire que la base c'est le comportement de ton compilateur (et de la plus part il me semble), il ne reste que le comportement est indéfnie. Pour un wrapper j'aurai plus vue une compostion qu'un héritage.

Citation:

---

Envoyé par Flob90

A part que ne détruire que la base c'est le comportement de ton compilateur (et de la plus part il me semble), il ne reste que le comportement est indéfnie.

---

:weird: de toutes façon, il y a bien un des destructeurs qui sera appelé et donc celui de la base le sera forcément non ?

Citation:

---

Envoyé par Flob90

Pour un wrapper j'aurai plus vue une compostion qu'un héritage.

---

le problème est que j'aimerais que mon wrapper soit transparent car j'aimerais que les utilisateurs d'une autre classe (qui l'utilisera en fait pour stocker des pointeurs) puissent l'utiliser sans avoir à passer par un get() ou un opérateur quelquonque et je me vois mal réécrir un wrapper par classe reproduisant toutes les méthodes (à moins que tu connaisse un moyen de le faire ....)

Nan, ce qu'il te dis c'est que :

Code:

---

1 2 3 4 5 6 7 8 9 10

class A {};   class B : public A {};     int main() { A* a = new B(); delete a; // Paf UB destructeur de A non virtuel et public }

---

Citation:

---

Envoyé par Goten

Nan, ce qu'il te dis c'est que :

Code:

---

1 2 3 4 5 6 7 8 9 10

class A {};   class B : public A {};     int main() { A* a = new B(); delete a; // Paf UB destructeur de A non virtuel et public }

---

---

he bien ? c'est certes un UB, mais un destructeur sera focrément appelé non que ce soit celui de A ou celui de B. et dans mon cas cela importe peu...

Ah, bah alors si ça te gêne pas d'avoir des comportements indéfinis ... J'espère que tu conçois pas un système critique / ayant trait à la sécurité..

(ou alors t'as pas saisi la notion d'UB)

Citation:

---

Envoyé par Goten

Ah, bah alors si ça te gêne pas d'avoir des comportements indéfinis ... J'espère que tu conçois pas un système critique / ayant trait à la sécurité..

(ou alors t'as pas saisi la notion d'UB)

---

Non, il n'est pas critique, mais je n'ai peut-être pas bien saisi les tenants et les aboutissant des UB .... :oops: pourrait-tu développer s'il te plais ?

merci :)

Citation:

---

Envoyé par méphistopheles

Non, il n'est pas critique, mais je n'ai peut-être pas bien saisi les tenants et les aboutissant des UB .... :oops: pourrait-tu développer s'il te plais ?

---

Pour faire simple, en cas de comportement indéfini (UB), l'implémentation est en droit de faire ce qu'elle souhaite (donc en toute rigueur, une implémentation qui reformate le disque dur ou qui envoie un mail d'insulte à tous tes contacts serait conforme), pas forcément toujours la même chose (en fonction des options d'optimisation par exemple) et n'a pas l'obligation de documenter le comportement.

Je vois le cas de la destruction de pointeur sur classe de base avec destructeur public non virtuel n'étant pas abordé par la norme, le compilo choisit le comportement à adopter. J'ignorer l'existences d' UB comme cela.

Pour ma part, j'ai finalement abandonné cette idée de wrapper car cela ne me permettais pas de résoudre mon problème et j'ai imposé à l'utilisateur d'avoir des pointeurs serializable.


enfin bon, quand c'est pas possible, il faut parfois lâcher l'affaire.


merci à tous

Citation:

---

Envoyé par méphistopheles

Je vois le cas de la destruction de pointeur sur classe de base avec destructeur public non virtuel n'étant pas abordé par la norme, le compilo choisit le comportement à adopter. J'ignorer l'existences d' UB comme cela.

---

En fait, ce n'est pas propre à l'absence de destructeur virtuel, c'est la définition même d'un UB (Undefined Behavior) : la norme n'impose rien, tout est permis.

Sinon, même si tu en as plus besoin, ton code avec boost::call_traits ne peut pas compiler car il ne peut pas créer le constrcuteur associé. La détermination des types dans les templates est automatique c'est vraie, mais faut quand même quelle soit possible, dans ton cas il peut y avoir une infinité de type T qui donnerait un constrcuteur valide, comment le compilateur choisie lequel prendre ? Il ne peut pas, il ne le fait pas (ou alors c'est un UB, à vérifier).