Discussion :

[Emmanuel Deloget]

<Modération>
Cette discussion est tiré de : http://www.developpez.net/forums/d10...t-multithread/

Reprise des messages :
</Modération>

Deux choses sur ces tâches courtes :

1) si l'ordre des tâches est important, je suis en train de réfléchir à la notion de pipeline généralisé (réversible et non réversible). Ca pourrait coller avec l'idée de continuer un traitement tant qu'il n'échoue pas. Que ceux qui m'aiment me suivent (par MP, dans un premier temps).

[...]

Je ne sais pas si ça peut aider ; c'était juste mon intervention peu utile du jour

[ICE Tea]

Dans mon cas l'ordre a une importance, ce sont des algos.
Par contre je ne connais pas ce concept de pipeline généralisé.

[Emmanuel Deloget]

Un pipeline y = P(x), c'est une suite de fonctions F0(), .... Fn() qui sont utilisées en séquence, de sorte que :

y = P(x) = Fn(Fn-1(....F0(x)...));

ou, dans un langage plus mathématique : P(x) = (Fn ∘ Fn-1 ∘ .... ∘ F1 ∘ F0)(x)

Le généraliser (dans une vision C++), ça serait donner la possibilité à l'utilisateur de

1) sélectionner les fonctions qui doivent être exécutées
2) sélectionner la façon dont les paramètres sont passés (paramètre de la fonction == résultat de la fonction précédente ? ou autre chose ?)
3) sélectionner la façon dont le pipeline s'arrête (arrêt unique à la fin ? arrêt entre chaque évaluation de fonction ?)

etc. Au final, ce pipeline généralisé serait donc une liste de tâche dont une particularité serait qu'elle peut fonctionner sous la forme d'un véritable pipeline. En C++, ça va être super tordu

[ICE Tea]

Pour compléter ta liste
- Il faut pouvoir introduire des étapes imbriquées ( sous-tâches )
- Comment gérer les étapes conditionnelles() (i.e if-elseif else )
- Pouvoir accéder aux étapes directement ( sans trop d'indirections...)

A défaut de faire l'implémentation il faut qu'on arrive à figer une Interface...

Ou en es tu ?

On n'arrive pas à t'envoyer de MP...

[Emmanuel Deloget]

Pour compléter ta liste
- Il faut pouvoir introduire des étapes imbriquées ( sous-tâches )
- Comment gérer les étapes conditionnelles() (i.e if-elseif else )
- Pouvoir accéder aux étapes directement ( sans trop d'indirections...)

Ca me semble exagéré. Le conditionnel peut être traité avec un pipeline dans une fonction qui effectue un test. Quand à l'ajout d'une fonction intermédiaire, ça n'a de sens que si son entrée et sa sortie ont le même type (ce qui peut arriver, bien évidemment). Par contre, j'ai du mal à voir un cas d'utilisation probant.

A défaut de faire l'implémentation il faut qu'on arrive à figer une Interface...

Comme il risque fort d'y avoir beaucoup de magie à l'intérieur (je le pressens), ça pourrait être un plus effectivement d'essayer de spécifier ça.

Je vais voir ça ce soir.

Ou en es tu ?

On n'arrive pas à t'envoyer de MP...

Boite pleine. Mais je l'ai vidé.

Quand à où j'en suis, et bien, j'ai beaucoup de choses à faire ; il faut que je corrige ce satané SHA256, que j'implémente une lib TCP/IP, que je revoie mon système de dispatch de messages ; à ce moment, je commencerais à avoir besoin d'un pipeline (puisque je vais recevoir des messages cryptés, encodés en base64 (ou pas, d'ailleurs), que je vais devoir décoder, décrypter, puis interpréter. L'interface que j'ai à l'heure actuel prévu n'est pas idéale, même si elle est pratique.

Code :

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

1
2
3
4
5
6
7
 
blowfish_cryptograph c;
blowfish_key k;
std::string b64_from_socket = ...;
std::vector<unsigned char> out;
c.decrypt(k, b64_from_socket, out, decoder::base64());
...

Peut mieux faire :

Code :

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

1
2
3
4
 
pipeline<???> p = make_pipeline(decoder::base64_pipe(), symetric_cryptograph_pipe<bf_engine>(k));
 
pipeline << b64_from_socket >> out; // ou quelque chose comme ça ; ça, c'est pas beau.

Dans l'idée, je ne devrais pas à me soucier de ce qu'il y a dans le pipeline ; ça devrait fonctionner tout seul.

[Flob90]

@Emmanuel Deloget: Je t'avais répondu, je te réenvoie le MP.

Pour la fin de ton message, j'aurais plus vue ca

Code :

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

1
2
 
out = pipeline(in);

Comme un foncteur, j'avais pas pensé au opérateur de flux, mais je verrais plus ca écrit avec les deux même opérateur :

Code :

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

1
2
3
4
 
out << pipeline << in;
//ou
in >> pipeline >> out;

En le fait d'avoir deux sens pourrait être pratique pour un pipeline réversible, AMA.

[JolyLoic]

Ca me semble exagéré. Le conditionnel peut être traité avec un pipeline dans une fonction qui effectue un test.

Si plusieurs étapes du pipeline dépendent de ce test, il me semble utile de le définir en tant qu'étape de pipeline à part entière.

[Emmanuel Deloget]

Des commentaires précédents

@Emmanuel Deloget: Je t'avais répondu, je te réenvoie le MP.

Pour la fin de ton message, j'aurais plus vue ca

Code :

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

1
2
 
out = pipeline(in);

Comme un foncteur, j'avais pas pensé au opérateur de flux, mais je verrais plus ca écrit avec les deux même opérateur :

Code :

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

1
2
3
4
 
out << pipeline << in;
//ou
in >> pipeline >> out;

En le fait d'avoir deux sens pourrait être pratique pour un pipeline réversible, AMA.

Quelques commentaires :

* si in et out (surtout out en fait) est un type lourd (disons pas exemple un std::vector<>), alors out = pipeline(in) va faire relativement mal. Il est préférable de faire pipeline(in, out) histoire de profiter du passage par référence.

* out << pipeline << in et in >> pipeline >> out sont plus intéressant. Celà signifie qu'on a redéfini les opérateurs ainsi :

pipeline<???>& operator<<(pipeline<???>& p, T in)
pipeline<???>& operator<<(T out, pipeline<???>& p)

Sachant que la second forme n'est utilisée que pour récupérer le résultat.

Ca me semble viable. Bien sûr, le problème reste le '???'

Des approches possibles

Sur les approches, on a plusieurs solutions. En partant du principe qu'un pipeline P est composé de n fonctions F0,...,Fn, et que ces fonctions sont telles que result_type(Fk) == arg_type(Fk+1), on comprends aisément que le type de chaque fonction Fk est différent. Du coup, on ne peut pas, à priori, stocker ça dans un conteneur simple.

A l'heure actuelle, dans la librairie standard, il n'y a qu'un seul conteneur ayant des propriétés similaires : std::tuple<>. On a besoin de plusieurs des fonctionnalités offertes par cette classe (mais un comportement différent indique une classe différente ; une encapsulation de std::tuple<> revenant à réécrire cette classe (car c'est dans son interface que se trouve la difficulté), c'est un des chemins qu'on peu prendre).

std::tuple est difficile à réécrire en C++98 (en fait, ça fait énormément de code ; ce n'est pas spécifiquement complexe (quoi que)), à cause du nombre variable d'argument templates (cf. l'implémentation dispo dans la librairie standard de g++ ou celle de Visual C++, dans le TR1 ; d'autres implémentations, plus simples, sont possibles).

Un exemple en limitant le nombre d'étages à 2 (pas compilé) :

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
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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
 
	 template <class S1>
	 class basic_pipeline_1
	 {
		 public:
			typedef S1 stage1_type;
			typedef typename stage1_type::output_type output_type;
			typedef typename stage1_type::input_type input_type;
 
		 private:
			 stage1_type m_stage1;
 
		 public:
			 basic_pipeline_1(const stage1_type& stage)
			 : m_stage1(stage)
			 { }
			 basic_pipeline_1(const basic_pipeline_1& other)
			 : m_stage1(other.m_stage1)
			 { }
			 virtual ~basic_pipeline_1()
			 { }
			 basic_pipeline_1& operator=(const basic_pipeline_1& other)
			 {
				 basic_pipeline_1(other).swap(*this);
				 return *this;
			 }
			 void swap(basic_pipeline_1& other)
			 {
				 std::swap(m_stage1, other.m_stage1);
			 }
			 void execute(const input_type& in, output_type& out)
			 {
				 m_stage1.execute(in, out);
			 }
 
	 };
 
	 template <class S1, class S2>
	 class basic_pipeline_2 : public basic_pipeline_1<S1>
	 {
		 public:
			typedef S2 stage2_type;
			typedef typename stage2_type::output_type output_type;
			typedef typename stage2_type::input_type input_type;
 
		 private:
			 stage2_type m_stage2;
 
		 public:
			 basic_pipeline_2(const stage1_type& s1, const stage2_type& s2)
			 : basic_pipeline_1(s1), m_stage2(stage)
			 { }
			 basic_pipeline_2(const basic_pipeline_2& other)
			 : basic_pipeline_1(other), m_stage(other.m_stage)
			 { }
			 virtual ~basic_pipeline_2()
			 { }
			 basic_pipeline_2& operator=(const basic_pipeline_2& other)
			 {
				 basic_pipeline_2(other).swap(*this);
				 return *this;
			 }
			 void swap(basic_pipeline_2& other)
			 {
				 basic_pipeline_1::swap(other);
				 std::swap(m_stage2, other.m_stage2);
			 }
			 void execute(const input_type& in, output_type& out)
			 {
				 typename basic_pipeline_1<S1>::output_type out1;
				 basic_pipeline_1::execute(in, out1);
				 m_stage1.execute(out1, out);
			 }
	 };
 
	 struct notype_t { };
 
	 template <class S1, class S2>
	 class pipeline : public basic_pipeline_2
	 { 
		 public:
			 pipeline(const S1& s1, const S2& s2) 
			 : basic_pipeline_2(s1,s2) 
			 { }
			 // ... other functions of interest
	 };
 
	 template <class S1>
	 class pipeline<S1,notype_t> : public basic_pipeline_1
	 {
		 public:
			 pipeline(const S1& s1) 
			 : basic_pipeline_1(s1)
			 { }
			 // ... other functions of interest
	 };
 
	 template <class S1>
	 make_pipeline(const S1& s1)
	 {
		 return pipeline<S1,notype_t>(s1);
	 }
 
	 template <class S1, class S2>
	 make_pipeline(const S1& s1, const S2& s2)
	 {
		 return pipeline<S1,S2>(s1,s2);
	 }

Ca fait beaucoup de code lorsqu'on arrive à 10 arguments templates Fort hereusement, on peut s'en sortir en utilisant judicieusement le pré-compilateur.

En C++1x, c'est beaucoup plus simple, grâce aux variadic templates.

Le problème principal de cette approche est que chaque étage ne peut (à la rigeur) être remplace que par un étage du même type. En fait, dans la plupart des cas, avec un écriture naïve, on est encore plus limité que ça : on ne peut remplacer un étage que par une autre instance du même étage.

On peut réduire ce problème en basant les étages sur une classe abstraite pipeline_stage<Input,Output>, mais on introduit alors le coût d'appel des fonctions virtuelles. Ca reste quand même un possibilité.

De plus, on ne traite pas vraiment les instructions conditionnelles (si ce n'est qu'un pipeline et un pipeline_stage ont la même interface, donc on peut mettre un pipeline dans un pipeline).

Cette approche n'est pas géniale en C++98. J'essaie de réfléchir à une autre approche, mais je n'en vois pas vraiment. On devrait aussi pouvoir passer par une type list - ce qui offre une autre possibilité d'écriture (pas encore refléchi à ce à quoi ça pourrait ressembler).

Ca fait toujours beaucoup de code à écrire, mais ça réduit nettement la profondeur de l'héritage.

[Emmanuel Deloget]

Histoire de démontrer ce que j'ai tenté d'expliquer dans le précédent message, voici du code C++98 qui permet de créer des pipelines qui prennent en compte jusqu'à 10 arguments templates.

L'instanciation a été allégée au maximum:

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
20
21
22
23
 
struct stage1 { ... }; // doit définir les types input_type, output_type 
                        // et la méthode execute(const input_type&, output_type&)
struct stage2 { ... }; // idem
struct stage3 { ... }; // idem
 
// la relation suivante doit être valide : 
// stage1::output_type convertible en stage2::input_type
// stage2::output_type convertible en stage3::input_type
// les conversions sont implicites (équivalent au static_cast<>)
 
int main()
{
  ekogen::pipeline<stage1,stage2,stage3> p = make_pipeline(stage1(), stage2(), stage3());
 
  // deux types d'appels:
  stage3::output_type out;
  stage1::input_type in;
 
  out = p(in); // chaine les 3 opérations stage1, puis statge2, puis stage3
  // ou
  p.execute(in, out);
}

Le code lui même a été particulièrement agaçant à écrire (promis). L'idée est de prévoir un fichier header paramétré par plusieurs macros bien choisies, et d'inclure plusieurs fois ce fichier dans le fichier header principal (ici, ekogen_pipeline.h qui inclut 10 fois bits/pipeline_details.h), en modifiant entre chaque inclusion les macros en question.

Ca donne ça :

(remarquer l'absence de guard ; c'est logique puisqu'il doit être inclus plusieurs fois)

Code bits/pipeline_details.h :

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
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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
 
template <PL_CLASS_LIST>
class PL_BASE_CLASS 
#if defined(PL_UPPER_BASE_CLASS)
: public PL_UPPER_BASE_CLASS
#endif
{
public:
	typedef PL_INPUT_TYPE input_type;
	typedef PL_OUTPUT_TYPE output_type;
#if defined(PL_UPPER_BASE_CLASS)
	typedef PL_UPPER_BASE_CLASS base_class_type;
#endif	
 
private:
	PL_VAR_TYPE m_function;	
 
protected:
	PL_BASE_CLASS()
	:
#if defined(PL_UPPER_BASE_CLASS)
	base_class_type(),
#endif
	m_function()
	{ }
 
	PL_BASE_CLASS(PL_ARGTYPE_LIST)
	: 
#if defined(PL_UPPER_BASE_CLASS)
	base_class_type(PL_UPPER_BASE_ARGS), 
#endif
	m_function(PL_LAST_ARG)
	{ }
 
	PL_BASE_CLASS(const PL_BASE_CLASS& other)
	:
#if defined(PL_UPPER_BASE_CLASS)
	base_class_type(other), 
#endif
	m_function(other.m_function)
	{ }
 
	virtual ~PL_BASE_CLASS()
	{ }
 
	void execute(const input_type& in, output_type& out)
	{
#if defined(PL_UPPER_BASE_CLASS)
		PL_SECONDARY_OUTPUT_TYPE temp;
		base_class_type::execute(in, temp);
		m_function.execute(temp, out);
#else
		m_function.execute(in, out);
#endif
	}
 
	void swap(PL_BASE_CLASS& other)
	{
		std::swap(m_function, other.m_function);
#if defined(PL_UPPER_BASE_CLASS)
		base_class_type::swap(other);
#endif
	}
 
public:
	void PL_FUNC_EVAL(const input_type& in, output_type& out)
	{ m_function.execute(in, out); }
 
	output_type PL_FUNC_EVAL(const input_type& in)
	{
		output_type out;
		PL_FUNC_EVAL(in, out);
		return out;
	}
 
};
 
template <PL_CLASS_LIST>
class pipeline PL_SPECIALIZED_LIST : public PL_BASE_CLASS<PL_TPL_ARG_LIST>
{
public:
	typedef PL_INPUT_TYPE input_type;
	typedef PL_OUTPUT_TYPE output_type;
	typedef PL_BASE_CLASS<PL_TPL_ARG_LIST> base_class_type;
 
public:
	pipeline() 
	: base_class_type()
	{ }
 
	pipeline(const pipeline& other)
	: base_class_type(other)
	{ }
 
	pipeline(PL_ARGTYPE_LIST)
	: base_class_type(PL_ARG_LIST)
	{ }
 
	virtual ~pipeline()
	{ }
 
	void execute(const input_type& in, output_type& out)
	{
	  base_class_type::execute(in, out);
	}
 
	output_type operator()(const input_type& in)
	{
		output_type out;
		execute(in, out);
		return out;
	}
 
	pipeline& operator=(const pipeline& other)
	{
		pipeline(other).swap(*this);
		return *this;
	}
 
	void swap(pipeline& other)
	{
		base_class_type::swap(other);
	}
};
 
template <PL_FUNC_CLASS_LIST>
pipeline PL_FUNC_TPL_ARG_LIST make_pipeline(PL_ARGTYPE_LIST)
{
  return pipeline PL_FUNC_TPL_ARG_LIST (PL_ARG_LIST);
}

Code ekogen_pipeline.h :

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
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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
 
#ifndef ekogen_pipeline_h
#define ekogen_pipeline_h
 
namespace ekogen { 
 
	namespace bits { struct notype_t { }; }
 
	// forward declaration
	template 
		<class,class,
		class,class,
		class,class,
		class,class,
		class,class> 
	class pipeline;
 
#define PL_BASE_CLASS basic_pipeline_1
#define PL_CLASS_LIST class F1
#define PL_ARGTYPE_LIST const F1& f1
#define PL_ARG_LIST f1
#define PL_TPL_ARG_LIST F1
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F1::output_type
#define PL_SPECIALIZED_LIST <F1,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F1
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_1
#define PL_LAST_ARG f1
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_2
#define PL_CLASS_LIST class F1,class F2
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2
#define PL_ARG_LIST f1,f2
#define PL_TPL_ARG_LIST F1,F2
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F2::output_type
#define PL_SPECIALIZED_LIST <F1,F2,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F2
#define PL_UPPER_BASE_CLASS basic_pipeline_1<F1>
#define PL_SECONDARY_OUTPUT_TYPE typename F1::output_type
#define PL_UPPER_BASE_ARGS f1
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_2
#define PL_LAST_ARG f2
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_3
#define PL_CLASS_LIST class F1,class F2,class F3
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3
#define PL_ARG_LIST f1,f2,f3
#define PL_TPL_ARG_LIST F1,F2,F3
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F3::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F3
#define PL_UPPER_BASE_CLASS basic_pipeline_2<F1,F2>
#define PL_SECONDARY_OUTPUT_TYPE typename F2::output_type
#define PL_UPPER_BASE_ARGS f1,f2
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_3
#define PL_LAST_ARG f3
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_4
#define PL_CLASS_LIST class F1,class F2,class F3,class F4
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4
#define PL_ARG_LIST f1,f2,f3,f4
#define PL_TPL_ARG_LIST F1,F2,F3,F4
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F4::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,F4,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F4
#define PL_UPPER_BASE_CLASS basic_pipeline_3<F1,F2,F3>
#define PL_SECONDARY_OUTPUT_TYPE typename F3::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_4
#define PL_LAST_ARG f4
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_5
#define PL_CLASS_LIST class F1,class F2,class F3,class F4,class F5
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4,const F5& f5
#define PL_ARG_LIST f1,f2,f3,f4,f5
#define PL_TPL_ARG_LIST F1,F2,F3,F4,F5
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F5::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,F4,F5,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F5
#define PL_UPPER_BASE_CLASS basic_pipeline_4<F1,F2,F3,F4>
#define PL_SECONDARY_OUTPUT_TYPE typename F4::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3,f4
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_5
#define PL_LAST_ARG f5
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_6
#define PL_CLASS_LIST class F1,class F2,class F3,class F4,class F5,class F6
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4,const F5& f5,const F6& f6
#define PL_ARG_LIST f1,f2,f3,f4,f5,f6
#define PL_TPL_ARG_LIST F1,F2,F3,F4,F5,F6
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F6::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,F4,F5,F6,bits::notype_t,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F6
#define PL_UPPER_BASE_CLASS basic_pipeline_5<F1,F2,F3,F4,F5>
#define PL_SECONDARY_OUTPUT_TYPE typename F5::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3,f4,f5
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_6
#define PL_LAST_ARG f6
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_7
#define PL_CLASS_LIST class F1,class F2,class F3,class F4,class F5,class F6,class F7
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4,const F5& f5,const F6& f6,const F7& f7
#define PL_ARG_LIST f1,f2,f3,f4,f5,f6,f7
#define PL_TPL_ARG_LIST F1,F2,F3,F4,F5,F6,F7
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F7::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,F4,F5,F6,F7,bits::notype_t,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F7
#define PL_UPPER_BASE_CLASS basic_pipeline_6<F1,F2,F3,F4,F5,F6>
#define PL_SECONDARY_OUTPUT_TYPE typename F6::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3,f4,f5,f6
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_7
#define PL_LAST_ARG f7
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_8
#define PL_CLASS_LIST class F1,class F2,class F3,class F4,class F5,class F6,class F7,class F8
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4,const F5& f5,const F6& f6,const F7& f7,const F8& f8
#define PL_ARG_LIST f1,f2,f3,f4,f5,f6,f7,f8
#define PL_TPL_ARG_LIST F1,F2,F3,F4,F5,F6,F7,F8
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F8::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,F4,F5,F6,F7,F8,bits::notype_t,bits::notype_t>
#define PL_VAR_TYPE F8
#define PL_UPPER_BASE_CLASS basic_pipeline_7<F1,F2,F3,F4,F5,F6,F7>
#define PL_SECONDARY_OUTPUT_TYPE typename F7::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3,f4,f5,f6,f7
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_8
#define PL_LAST_ARG f8
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST 
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_9
#define PL_CLASS_LIST class F1,class F2,class F3,class F4,class F5,class F6,class F7,class F8,class F9
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4,const F5& f5,const F6& f6,const F7& f7,const F8& f8,const F9& f9
#define PL_ARG_LIST f1,f2,f3,f4,f5,f6,f7,f8,f9
#define PL_TPL_ARG_LIST F1,F2,F3,F4,F5,F6,F7,F8,F9
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F9::output_type
#define PL_SPECIALIZED_LIST <F1,F2,F3,F4,F5,F6,F7,F8,F9,bits::notype_t>
#define PL_VAR_TYPE F9
#define PL_UPPER_BASE_CLASS basic_pipeline_8<F1,F2,F3,F4,F5,F6,F7,F8>
#define PL_SECONDARY_OUTPUT_TYPE typename F8::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3,f4,f5,f6,f7,f8
#define PL_FUNC_CLASS_LIST PL_CLASS_LIST
#define PL_FUNC_TPL_ARG_LIST PL_SPECIALIZED_LIST
#define PL_FUNC_EVAL execute_stage_9
#define PL_LAST_ARG f9
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
#define PL_BASE_CLASS basic_pipeline_10
#define PL_CLASS_LIST class F1,class F2=bits::notype_t,class F3=bits::notype_t,\
					  class F4=bits::notype_t,class F5=bits::notype_t,class F6=bits::notype_t,\
					  class F7=bits::notype_t,class F8=bits::notype_t,class F9=bits::notype_t,\
					  class F10=bits::notype_t
#define PL_FUNC_CLASS_LIST class F1,class F2,class F3,class F4,class F5,class F6,class F7,class F8,class F9,class F10
#define PL_ARGTYPE_LIST const F1& f1,const F2& f2,const F3& f3,const F4& f4,const F5& f5,const F6& f6,const F7& f7,const F8& f8,const F9& f9,const F10& f10
#define PL_ARG_LIST f1,f2,f3,f4,f5,f6,f7,f8,f9,f10
#define PL_TPL_ARG_LIST F1,F2,F3,F4,F5,F6,F7,F8,F9,F10
#define PL_INPUT_TYPE typename F1::input_type
#define PL_OUTPUT_TYPE typename F10::output_type
#define PL_SPECIALIZED_LIST
#define PL_VAR_TYPE F10
#define PL_UPPER_BASE_CLASS basic_pipeline_9<F1,F2,F3,F4,F5,F6,F7,F8,F9>
#define PL_SECONDARY_OUTPUT_TYPE typename F9::output_type
#define PL_UPPER_BASE_ARGS f1,f2,f3,f4,f5,f6,f7,f8,f9
#define PL_FUNC_TPL_ARG_LIST <F1,F2,F3,F4,F5,F6,F7,F8,F9,F10>
#define PL_FUNC_EVAL execute_stage_10
#define PL_LAST_ARG f10
 
#include "bits/pipeline_details.h"
 
#undef PL_BASE_CLASS
#undef PL_CLASS_LIST
#undef PL_ARGTYPE_LIST
#undef PL_ARG_LIST
#undef PL_TPL_ARG_LIST
#undef PL_INPUT_TYPE
#undef PL_OUTPUT_TYPE
#undef PL_SPECIALIZED_LIST
#undef PL_VAR_TYPE
#undef PL_UPPER_BASE_CLASS
#undef PL_SECONDARY_OUTPUT_TYPE
#undef PL_UPPER_BASE_ARGS
#undef PL_FUNC_CLASS_LIST
#undef PL_FUNC_TPL_ARG_LIST
#undef PL_FUNC_EVAL
#undef PL_LAST_ARG
 
}
 
#endif // ekogen_pipeline_h

Ce type de code profitte très bien d'un générateur (sous la forme d'un script shell ou perl) parce que à écrire, c'est désagréable à souhait. Mais bon, ça fonctionne, et à moins de se taper l'intégralité du code à écrire, c'est une des façon les plus simple d'arriver à son but. A noter que si on souhaite supporter les pipeline reversible, on doit refaire la même chose mais pour la classe reversible_pipeline (pas la même interface).

Un version C++0x est en cours d'écriture - elle devrait être beaucoup plus compacte, et beaucoup plus claire (pour peu qu'on lise aisément les variadic templates).

On notera qu'avec tout ça, il y a encore des tas de choses qui ne sont pas gérées :

* les conditions : je pense qu'il pourrait être utile de prévoir un objet condition qui encapsule un étage de pipeline (le pipeline ayant la même interface que ses étages, on peut faire un pipeline de pipeline de pipeline...)

* la modification au runtime d'un étage donné ; le problème est qu'on ne sait pas atteindre les étages autrement que par un nom spécifique (voir l'exemple de la méthode execute_stage_X() dans basic_pipeline_X(). Je ne sais pas écrire un operator[] de manière fiable, sauf dans le cas où tous les types de fonction sont différents - et encore, ça nécessiterait trois tonnes de directive using bien placées pour réimporter les fonctions dans la classe fille). Je peux toujours faire des fonctions Fx& fx() (avec x variant de 1 à 10). Pas l'idéal, mais c'est possible.

* toujours sur ce même sujet, si on veux pouvoir changer le type dymanique d'un étage particulier, il faut que cet étage encapsule l'étage réel - on garde des copies des étages, et non pas des références.

Bref, ça fait pas mal de problèmes à résoudre, donc si quelqu'un à une solution, je suis preneur...

[Joel F]

J'ai ca qui traine dans un vieux projet qui date de ma these. Avec Proto (ou juste des expressions templates), on casse le besoin d'avoir X parametres templates:

Code :

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

1
2
 
boost::function<T(U)> p = f | g | h | l;

l'AST proto se construie recursivement et une transform statique trasnforme l'AST en liste de fonction a appelé, vérifie les conversiosn des i/o entre fonctions et renvoient un objet fonction classique. Bonus point, la syntaxe de composition reste tres simple. Dans le cas ou les f ne sont pas des Poly;orphic Function Object, un adapteur genre seq() est trivial a ecrire.

[Goten]

C'est juste un poil "lourd" pour l'utilisateur qui doit faire de ses PFO des terminaux. (fin, au moins un en tout cas). Mais ça reste beaucoup plus attrayant que la solution bruteforce, avec une syntaxe à la boost.range adaptator, t'as le code pour ce DSEL qui traine quelque part?

Edit : ça me fait penser au dernier article de Monsieur Niebler sur C++ next sur la composition de fonction (je préfère ce terme à celui de pipeline).

[Joel F]

https://github.com/jfalcou/quaff/tree/master/attic

c'est tre slaid, sans doc et avec un back end MPI. Mais l'idee est la.
Le code est plus complexe car je gere plusieurs schemas de composition parallele

[Goten]

Ah ok c'est Quaff, ouai donc j'ai déjà regarder. Jpensais que t'avais un toy code plus vieux en fait :p.

[Emmanuel Deloget]

Il faut que je regarde ça Cet après midi ; j'en ai proffité pour lire l'article sur c++next ; c'est plutôt intéressant, même si au final la solution envisagée n'est pas très loin de celle que je propose conceptuellement.

Je dois faire une évolution basée sur le système des duo<> présentée dans le bouquin de Josuttis & (je sais plus qui), histoire de limiter la profondeur d' héritage.

[Goten]

Il faut que je regarde ça Cet après midi ; j'en ai proffité pour lire l'article sur c++next ; c'est plutôt intéressant, même si au final la solution envisagée n'est pas très loin de celle que je propose conceptuellement.

Je dois faire une évolution basée sur le système des duo<> présentée dans le bouquin de Josuttis & (je sais plus qui), histoire de limiter la profondeur d' héritage.

Sauf qu'avec la récursion son code est beaucoup plus cour .

[Emmanuel Deloget]

Sauf qu'avec la récursion son code est beaucoup plus cour .

Voui, c'est pour ça qu'il m'intéresse

[Joel F]

si j'ai 5mn, j'extrairais la partie pipeline du truc, ca doit faire genre 35 lignes.

[poukill]

Pour info,
NVL++ a une partie sur les pipeline : example ici

[Emmanuel Deloget]

Pour info,
NVL++ a une partie sur les pipeline : example ici

Son idée de baser les pipelines sur des std::vector<variant<> >, c'est à la fois bien, à la fois pas bien. Bien parce que ça permets de ne pas s'inquiéter du type d'entrée et de sortie des données de chaque étage ; on peut donc stocker des fonctions qui n'ont pas de lien entre elles.

Pas bien pour exactement la même raison ; du coup, pour faire un vrai pipeline, il est obligé de spécifier le type d'entrée et de sortie de chaque étage lorsqu'il instancie le pipeline ; et ça, c'est déjà moins beau (10 paramètres templates pour deux étages de pipeline (construction de l'instance de pipe_stream2).

si j'ai 5mn, j'extrairais la partie pipeline du truc, ca doit faire genre 35 lignes.

Dis moi juste où elle est cachée. Je vais regarder ça par moi-même.

[Goten]

Son idée de baser les pipelines sur des std::vector<variant<> >, c'est à la fois bien, à la fois pas bien. Bien parce que ça permets de ne pas s'inquiéter du type d'entrée et de sortie des données de chaque étage ; on peut donc stocker des fonctions qui n'ont pas de lien entre elles.

Pas bien pour exactement la même raison ; du coup, pour faire un vrai pipeline, il est obligé de spécifier le type d'entrée et de sortie de chaque étage lorsqu'il instancie le pipeline ; et ça, c'est déjà moins beau (10 paramètres templates pour deux étages de pipeline (construction de l'instance de pipe_stream2).



Dis moi juste où elle est cachée. Je vais regarder ça par moi-même.

vector<variant> pas une bonne idée du tout... c'est lent.


regarde dans :
quaff / attic / core / language / grammar / (et notamment definition.hpp)