Discussion :

[Joel F]

Je vois bien. Ceci dit, ce concept est modélisé dans un type statique (la classe de base des flux) et donc vérifié de manière statique dès lors qu'on utilise une classe dérivée de la classe flux. C'est effectivement strictement là même chose, dans le sens ou ce n'est même pas le runtime qui vérifie le concept - mais bien le compilateur. Par contre, la décision de l'algorithme a exécuter s'effectue au runtime.

oui

Je me demande dans quelle mesure ce n'est pas un message de la communauté des développeurs de FF à la communauté des programmeurs...

Effectivement :E

Qui dit éducation dit aussi niveau d'éducation. Si sur une équipe réduite tu peux espérer d'avoir un niveau d'éducation et des connaissances homogène, ce n'est plus le cas dès que tu élargis l'équipe. Tu ne peux pas espérer que tout le monde ait le même niveau de maîtrise, ce qui peut avoir de graves conséquences pendant le développement et la maintenance.

J'en suis bien conscient & c'est ce que j'aessaye aussi d'inculquer à mes étudiants.

Concept que l'on retrouve dans la C++SL, où les flux dérivent tous des mêmes classes std::istream et std::ostream. Je n'ai pas pour habitude de recopier le design des autres, par contre je m'interroge souvent sur le pourquoi de leurs choix. De temps en temps, ça a du sens, de temps en temps ça n'en a pas. Même si il est évident que la notion de templates est postérieure à la première implémentation des flux, force est de constater que l'implémentation retenue pour ces flux fait intervenir les templates. A partir de là, on peut se demander si il était vraiment nécessaire de faire dériver tous les flux d'une série de même classe, ou si c'est un véritable choix d'architecture. Je penche pour la seconde solution, et je pense en outre que c'est un bon choix : un flux peut être passé en paramètre à une fonction et le choix de l'algorithme a utiliser s'effectue au runtime.

Alors attention, tu peux faire des templates sans faire de prog générique stricto sensu et c'est le cas dasn les flux de iostream je pense.

Ici, je pense que oui, on a vraiment besoin de connaitre et d'effectuer le choix au runtime ne serait-ce que pour le use-case de la redirection.

Après, je ne voudrait pas donner l'impression que je ne suis pas d'accord avec ce qui a été dit : je le suis (au moins en partie), même si je reste très circonspect sur tout ce qui concerne la création d'abstractions artificielles.

Elle n'est pas artificielle, c'ets la meme que celle faite en POO classique, sauf qu'elle prend une forme différente.

[camboui]

Je reviens comme annoncé plus tôt avec un exemple concret d'implémentation possible.
J'ai volontairement omis les paramètres, les valeurs retour, etc, afin de faciliter la lisibilité du propos.

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
class file_std
{
	read();
	seek();
};
 
template<class F>
class file_buffered: private F
{
	read()
	{
	 ...
	 F::read();
	 ...
	}
	seek()
	{
	 ...
	 F::seek();
	 ...
	}
};
 
template<class F>
class file_compressed: private F
{
	read()
	{
	 ...
	 F::read();
	 ...
	}
	seek()
	{
	 ...
	 F::seek();
	 ...
	}
};
 
template<class F>
class file_system: private F
{
	read()
	{
	 ...
	 F::read();
	 ...
	}
	seek()
	{
	 ...
	 F::seek();
	 ...
	}
};

Supposons que j'aie un ensemble de fichiers binaires dont je connais le format. Je souhaite accéder à leur contenu avec par exemple une instance de la class file_std en faisant des seek() et des read() classiques (file_std serait un wrap des fonctions io, ou des fstream, ou de l'API windows, etc, au choix):
file_std f("chemin/monfichier.bin");

Supposons maintenant que je veuille améliorer les performances par une bufférization des accès aux fichiers, et cela sans changer l'implémentation en aval bien sûr. L'instantiation serait:
file_buffered<file_std> f("chemin/monfichier.bin");

Supposons ensuite que je veuille accéder aux fichiers alors qu'ils sont compressés (cf les fonctions LZread, LZseek, etc, de l'API windows), mais en aval le code d'accès à la structure binaire d'origine ne change toujours pas:
file_compressed<file_std> f("chemin/monfichier.bin");

Supposons encore que je veuille accéder aux fichiers alors qu'il sont englobés dans un seul et même fichier "system" (par simple concaténation, ou autre format plus complexe):
file_system<file_std> f("chemin/monsytem:monfichier.bin");

Et supposons enfin que je veuille une combinaison quelconque de tout ces accès possibles, par exemple:
file_buffered<file_system<file_compressed<file_std> > > f("chemin/monsytem:monfichier.bin");
Ou même:
file_buffered<file_system<file_compressed<file_buffered<file_std> > > > f("chemin/monsytem:monfichier.bin");

Comme on peut le constater toutes ces classes partagent la même interface. Cela permet d'instancier celle de son choix indépendament de l'usage qui en est fait dans un traitement en aval. Chaucune peut aussi être le paramètre template d'une autre, dans n'importe quel ordre (exception faite de file_std qui n'est pas template).

Alors voilà, les template<> rendent l'usage pour l'utilisateur assez confortable, mais le code à se farcir dans les template peut être assez "lourd", les temps de compilation long, tout comme le code machine généré.
Une approche POO est plus simple (plus facile à mettre au point et à débugger), mais les méthodes virtuelles (nécessaires dans ce cas uniquement) sont inutiles à partir du moment où la structure des fichiers binaires de départ est connue dès la compilation.

Ceci étant, je n'ai pas encore parlé du "traitement" dont question dans le premier post de cette discussion:
Traitement<file_buffered<file_system<file_compressed<file_buffered<file_std> > > > >
f("chemin/monsytem:monfichier.bin");
On va faire simple, on va dire que le traitement consiste à lire un fichier texte (utf8 ou utf16be ou utf16le ou...) ligne par ligne

Retour à la question initiale: la programmation générique est-elle oportune dans ce cas de figure ?