Discussion :

[PhilIvey]

déjà wikipedia n'est pas une source toujours fiable (mais il ne tient qu'à nous de l'améliorer ^^)

ensuite, la reflexion contient l'introspection et l'intercession, et avec juste l'introspection on est loin de la meta-programmation ^^

On est un peu hors sujet,par rapport à la discussion initiale, j'ai l'impression


je connais pas le Smalltalk, donc ne serait pas comparer les possibilités d'intercession à ce qui est possible en c#.

Mais les API présentes dans Reflection.Emit, TypeBuilder et compagnie, te permettent de créer des types dynamiques, d'ajouter des champs,constructeurs,méthodes,etc...à ce type et d'obtenir une forme d'intercession, en plus de l'introspection.

[loufoque]

Notre code de base est ancien,( fin des années 90), et nous avons entrepris il y a quelques années, de nettoyer certaines parties,
et de rendre l'architecture plus flexible aux modifications.

Une des solutions se basait sur Boost MPL,boost::enable_if , pour certaines factories, et Boost Fusion pour génériser les traitements en sortie de parsing.

C’était la solution la plus concise et élégante, et celle qui permettait le maximum de vérification statique du code mais l'impact sur les temps de compilation a été proprement calamiteux.

Pour te donner un indicateur très imparfait, le soft installé sur le poste client peut atteindre 10 Go...
Tout n'est pas bien sur en C++.... .

La programmation générique nécessite des connaissances et compétences particulières, et il faut savoir faire les bons compromis.
Si on ne sait pas bien s'en servir, il est très facile de faire des choses lentes et non-efficaces avec, comme avec tout autre outil de programmation.

Utiliser enable_if à tort et à travers, par exemple, c'est à éviter. La résolution de surcharge avec du SFINAE est linéaire. Elle est aussi difficilement extensible.
S'il y a des dispatch conséquents à faire, ce n'est pas le bon mécanisme. La surcharge classique avec des schémas d'héritage est à préférer, comme le fait par exemple le standard avec les tags d'itérateur.

Les tuples, c'est vraiment intéressant uniquement si les types sont différents. J'ai déjà vu du code où on utilisait des tuples où tous les éléments étaient les mêmes à la place de tableaux. Ça ralentit les temps de compil inutilement, juste pour unroller des tableaux qui le seraient de toutes manières avec un compilateur décent. Si cet unrolling n'est pas critique, autant utiliser des tableaux.

L'exécutable de 10 Go est a priori un indicateur d'une mauvaise utilisation de techniques de génération de code. Ce n'est pas une quantité de code machine normale.

[PhilIvey]

Utiliser enable_if à tort et à travers, par exemple, c'est à éviter. La résolution de surcharge avec du SFINAE est linéaire. Elle est aussi difficilement extensible.
S'il y a des dispatch conséquents à faire, ce n'est pas le bon mécanisme. La surcharge classique avec des schémas d'héritage est à préférer, comme le fait par exemple le standard avec les tags d'itérateur.

Tu as tout a fait raison. C'est la solution qui a été retenue lors de la revue de code, ie ajouter un niveau d’héritage. Je ne sais pas si c’était enable_if qui était en cause , ou plutôt toute la plomberie MPL en amont, que le gars n'avait pas optimisé. Je demanderais à l'auteur.

On a peut être eu peur à l'époque que peu de gens soient capable de le maintenir...

ça devait être en substance des choses de ce type ( avec quelque mpl::not_,mpl::or_ dans certains cas, dans certains cas plus complexes)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
using namespace boost::mpl;
using namespace std;
 
typedef copy<types1,
	              front_inserter<types2>
                        >::type final_types;
 
struct Process
{						
	template <typename T>
	typename boost::enable_if<boost::mpl::contains<final_types, T>, void>::type
	operator()(vector<string> tokens)
	{
		/*
		Traitement quelconque
		*/
	}
};

Les tuples, c'est vraiment intéressant uniquement si les types sont différents. J'ai déjà vu du code où on utilisait des tuples où tous les éléments étaient les mêmes à la place de tableaux. Ça ralentit les temps de compil inutilement, juste pour unroller des tableaux qui le seraient de toutes manières avec un compilateur décent. Si cet unrolling n'est pas critique, autant utiliser des tableaux.

Le but etait de faire du "parsing into structs"

Il y avait quelques de dizaines de structs, donc le seul point commun, était de subir des traitements quasi-identiques, avec de nombreuses combinaisons de types pour les champs, et des tailles de quelques champs à une trentaine.

C'est le cas de figure idéal pour utiliser des tuples, si on fait fi des temps de compilation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
namespace TotoSpace
{
	struct Toto : public TotoBase
	{
		Toto(){init();}
		string totoname;
		long field1;
		long field2;
		double field3;
	};
}
 
BOOST_FUSION_ADAPT_STRUCT(
	TotoSpace::Toto,
		(string,totoname)
		(long, field1)
		(long, field2)
		(double, field3))

BOOST_FUSION_ADAPT crée un tuple à partir des champs de la struct,
et permet d'itérer dessus.

L'exécutable de 10 Go est a priori un indicateur d'une mauvaise utilisation de techniques de génération de code. Ce n'est pas une quantité de code machine normale.

10 Go
C'est la suite logicielle avec plusieurs centaines de DDL, des dizaines d’exécutables....