Impl�mentation des std::stream avec variadic template

Version imprimable

30/05/2011, 15h32
teto

Impl�mentation des std::stream avec variadic template

Bonjour,

Je me lance dans l'univers fabuleux de C++0x et je voulais changer mon logger pour qu'il utilise les variadic template au lieu du chainage d'appel comme actuellement:
Logger(Error) << "test" << 4 << 5.f;
L'operateur surcharg� << �crit dans un stream.

Je me pose 2 questions:
-existe-t-il une version variadic des streams standards. Genre stream.push(...on metautantdeparamsquonveutici)
-est-ce que cette technique ne va pas faire grossir mon executable ?
(Si le compilo g�n�re un prototype de fonction � chaque appel du logger ou presque)

Matt

Bonjour,

Peut �tre que dans un premier temps - avant de chambouler tout le code de la classe logger - serait-il suffisant de wrapper l'appel dans une fonction libre variadique r�cursive ? Qqchose du 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 29 30 31 32 33 34 35 #include <iostream> #include <string> struct Logger { template<typename T> Logger& operator << (const T& val) { std::cout << val << std::endl; return *this; } }; template <typename T> void log(Logger& l, T&& val) { l << std::forward<T>(val); } template <typename Head, typename... Tail> void log(Logger& l, Head&& head, Tail&&... tail) { log(l << std::forward<Head>(head), std::forward<Tail>(tail)...); } int main() { int i = 0; float f = 5.0f; std::string s = "toto"; Logger l; log(l, i, f, s, 1, 6.0, "titi"); }
Citation:

-existe-t-il une version variadic des streams standards. Genre stream.push(...on metautantdeparamsquonveutici)

Pas � ma connaissance.

Citation:

-est-ce que cette technique ne va pas faire grossir mon executable ?
(Si le compilo g�n�re un prototype de fonction � chaque appel du logger ou presque)

Bonne question. Qui n'est jamais r�ellement abord� dans les articles/proposal/post sur forum tournant autour des templates variadiques :mrgreen:
J'imagine que pour une utilisation classique (comme montr� plus haut, avec des appels r�cursifs d�pilant les arguments un par un), tout le monde compte sur le fait qu'un bon compilateur doit pouvoir assez facilement inliner tous les appels r�cursifs... mais j'en mettrais pas ma main � couper :aie:

30/05/2011, 17h12
victor_gasgas

Bonjour,

N'�tant pas encore trop familier du monde des rvalues references en c++0x, si tu pouvais expliquer leur fonctionnement ici, mais aussi l�int�r�t de les utiliser. Ou encore l'emploi de std::forward que je ne connaissais pas encore jusque l�.

Je sais que peut �tre des questions ci-dessus certaines sont s'en doute mal tourner, mais j'ai un peut de mal avec tous ces T&& :oops:

Merci de ta compr�hension!

P.S : j'ai regarder sur ce site FAQ c++0x qui explique de fa�on claire et concise le prochain standard, mais la pour les rvalues je s�che...
30/05/2011, 18h34
teto

merci pour ta r�ponse rapide arzar. La classe "Logger" que je modifie est une classe perso donc ca pose aps de pb que je la modifie (mais je pensais faire eun wrapper comme tu dis par souci de compatibilit� / tests).

Dommage que tu n'aies pas de r�ponse sur la taille de l'ex�cutable, je suppose qu'il faudrait tester.
Inliner est-il une solution ? Il me semble que le compilo copie le code plut�t que de g�n�rer la fonction, le r�sultat peut s'av�rer encore plus gros que s'il avait g�n�r� la fonction ! non ?
30/05/2011, 19h38
3DArchi

Salut,

Citation:

Envoy� par teto

Inliner est-il une solution ? Il me semble que le compilo copie le code plut�t que de g�n�rer la fonction, le r�sultat peut s'av�rer encore plus gros que s'il avait g�n�r� la fonction ! non ?

S'il s'agit d'une combinaison utilis�e qu'une seule fois, alors le passage par fonction a peu d'int�r�t. Ou si le code 'utile' est plus petit que le passage par fonction (avec l'empilement des param�tres, la pr�paration de la pile, puis le d�pilement, le saut et le retour). Ou si le compilateur sait faire des optimisations car tout est dispo. etc. Bref, difficile de dire � priori si inline va g�n�rer un code plus ou moins important.

Ceci dit cette remarque porte en implicite un �-priori qui fait des ravages en C++ (embarqu� en particulier) : Non, les g�n�riques ne g�n�rent pas du code bloat !!!! Pas plus que de cr�er 45000 surcharges et/ou classes avec des param diff�rents mais impliquant une violation du DRY (don't repeat yourself) et une production du code y compris pour ce qui n'est pas utilis� !!!

Enfin question de curiosit� : pourquoi remplacer un syst�me de log qui ressemble � des flux (et qui semble assez naturel) par un syst�me par appel de fonction ? Pour l'exercice de style ?