Discussion :

[camboui]

Voici un exemple de code générique:

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
template<class F>
class Traitement: public F
{
public:
	Traitement() {}
	void Faire()
	{
		//lire des données
		F::lire();
		//calculer les données lues
		//...
		//sauver les résultats du calcul
		F::sauver();
	}
};

Et voici le même code en POO:

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
//définition
class Traitement
{
	fichier_base & m_f;
public:
	Traitement(fichier_base & f): m_f(f) {}
	void Faire();
};
 
//déclaration
void Traitement::Faire()
{
	//lire des données
	m_f.lire();
	//calculer les données lues
	//...
	//sauver les résultats du calcul
	m_f.sauver();
}

L'avantage du premier code est qu'il n'y a aucune contrainte sur le paramètre template F, seules les fonctions membres F::lire() et F::sauver() doivent exister.
L'inconvénient est que le code est exposé (puisque template); il peut aussi être assez lourd.

L'avantage du second code est qu'il n'est plus exposé.
Par contre fichier_base doit être une classe de base dont les fonctions membres lire() et sauver() doivent être virtuelles. Les multiples implémentations dont on pourrait avoir besoin pour faire() le Traitement devront obligatoirement dériver de fichier_base (lire et sauver dans une db, un fichier, un pipe, un socket, un container en mémoire, etc, soit rien en commun si ce n'est la définition des méthodes lire et sauver).
Ce que je trouve dommage est qu'il faille écrire une hiérarchie de classes avec fonctions membres virtuelles alors qu'en définitive l'usage qui sera fait de cette hiérarchie sera figée lors de la conception, et donc de la compilation. Les méthodes virtuelles ne seront pas utiles et, dans une certaine mesure, un ralentissement à l'exécution.
En fait, le polymorphisme en puissance de fichier_base ne sera pas utilisé en pratique à l'exécution. Malgré cela, je pense c'est le bon choix de conceptualiser dans ce cas-ci.
Je commençais à avoir une tendance ces derniers temps à "templatiser" à tout va mais je me trouve face à certaines limites.

A vous lire, en espérant que vous ayez compris la problématique
Merci.

[Joel F]

Si tu n'as pas besoin du polymorphisme au runtime, prog. générique.
Si tu en as VRAIMENT besoin, polymorphisme dynamique à l'ancienne.

Typiquement dans ton cas, F doit vérifier le concept disons de "SerializableType", quite à ecrire le cocnept-check qui va bien (et c'ets pas trop trop dur dans ce cas) et ca suffit largement.

[koala01]

Salut,

Je suis d'accord avec la synthèse faite par Joel, mais je voudrais t'inciter à aller plus loin dans ta réflexion.

Par exemple, en quoi le fait que le code de la classe template soit exposé est-il un inconvénient

Dans le même ordre d'idée, si ce fait est un tel inconvénient, rien ne t'empêche de "scinder" le fichier contenant ta classe template en deux (ou en plus), sous une forme proche de
Traitement.hpp(fournis avec la bibliothèque)

Code :

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

1
2
3
4
5
6
7
template<class F>
class Traitement: public F
{
public:
	Traitement();
	void Faire();
};

Traitement.ipp (utilisé dans l'application)
#include <Traitement.hpp> // il faut bien avoir la définition de la classe

Code :

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

1
2
3
4
5
6
template <class F> inline Traitement<F>::Traitement(){}
template <class F>
inline void Traitement<F>::Faire()
{
    /*...*/
}

SomeClass.hpp (la classe qui utilise réellement Traitement)

Code :

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

1
2
3
4
5
6
7
8
/* la définition de la classe suffit... 
 * si on en a vraiment besoin...
 */
#include <Traitement.hpp> 
class SomeClass
{
    /*...*/
};

SomeClass.cpp

Code :

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

1
2
3
4
5
6
7
8
9
 
#include <SomeClass.hpp>  
/* pour avoir l'implémentation des fonctions membre de traitement */
#include <Traitement.ipp>
void SomeClass::doSomething()
{
    Traitement<Basard> truc;
    truc.Faire();
}

[Davidbrcz]

L'inconvénient est que le code est exposé (puisque template); il peut aussi être assez lourd.

Suis je le seul à ne pas comprendre ce que tu entends par exposé ?

Enfin il faut comprendre que templates et POO ne sont pas parallèles mais orthogonaux. Ils ne s'opposent pas, ils se complètent.

[koala01]

Suis je le seul à ne pas comprendre ce que tu entends par exposé ?

Peut-être...

Quel sens donnes-tu à cette phrase, car le sens que je lui donne est peut être (surement, à en lire ta question ) différent

Enfin il faut comprendre que templates et POO ne sont pas parallèles mais orthogonaux. Ils ne s'opposent pas, ils se complètent.

Tout à fait, et ils se marient parfaitement bien

[Davidbrcz]

Peut-être...

Quel sens donnes-tu à cette phrase, car le sens que je lui donne est peut être (surement, à en lire ta question ) différent

Bah exposé, visible de tous, public en somme.

Dans son premier code, il peut rendre ses fonctions F::lire et F::sauver protected de telle sorte qu'elles ne soient connues que par des classes dérivées. A l'inverse, dans le second, soit tout le monde connait les fonctions lire et sauver de fichier_base, soit elles sont privées mais cela impose une utilisation de l'amitiée (a moins d'utiliser une nested classe qui peut palier en partie le problème en évitant d'afficher la classe à tout le monde)

J'aurais donc tendance à préférer la 1er solution en adaptant au besoin s'il faut du polymorphisme dynamique.

Mais sans plus de détails, pas moyen de répondre de façon précise.

[Joel F]

Salut,

Je suis d'accord avec la synthèse faite par Joel, mais je voudrais t'inciter à aller plus loin dans ta réflexion.

<snip>

c'est exactement le genre de chose que l'on propose (des classes d'adaptations). Soit tu ecris ta classe qui expose les pré-requis de ton Concept, soit tu fournis une classe dont tu peux hériter (et qui souvent utilsie le CRTP) pour permettre au gens d'adapter leur classe qui ne respecte pas le Concept.

Je ne saurais t'encourager à lire la page de Douglas Gregor sur le sujet ou de jeter un oiel au "Elements of Programming" de Stepanov.

[koala01]

c'est exactement le genre de chose que l'on propose (des classes d'adaptations). Soit tu ecris ta classe qui expose les pré-requis de ton Concept, soit tu fournis une classe dont tu peux hériter (et qui souvent utilsie le CRTP) pour permettre au gens d'adapter leur classe qui ne respecte pas le Concept.

Il semblerait que tu aies très mal interprété mon intervention...

Je disais donc:
-1 Je suis tout à fait d'accord avec ta "synthèse" (approche générique si pas de polymorphisme au runtime approche OO, voir mélange des deux s'il y en a)

-2 (en m'adressant particulièrement à camboui)je proposais de pousser la réflexion un peu plus loin:

• en réfléchissant en quoi l'approche générique serait un inconvénient
• en présentant (si c'est vraiment un inconvénient) une manière d'éviter que tout un chacun n'aie accès à l'implémentation des fonction, bien que ce ne soit qu'une approche purement générique
• en confirmant ce que vous (toi et david) aviez dit, à savoir que les deux se marient très bien (bon, ca, c'était l'autre intervention de ma part )

Autrement, j'étais on ne peut plus d'accord avec toi, et bien conscient de la manière dont il faut s'y prendre

[Joel F]

<snip>

non c'est moi qui sait pas quoté :o
Donc oui j'ai bien compris, et je faisais la remarque que ta suggestion était souvent celle préconisée. Ma deuxiéme phrase s'addressait au PO.

Toutes mes confuse.

[Jean-Marc.Bourguet]

Je commençais à avoir une tendance ces derniers temps à "templatiser" à tout va

Tu es loin d'etre le seul. Joel semble atteint de ;a meme malalie:

Si tu n'as pas besoin du polymorphisme au runtime, prog. générique.
Si tu en as VRAIMENT besoin, polymorphisme dynamique à l'ancienne.

Je continue a avoir beaucoup de mal a parler de conception -- pour moi la
conception est toujours une affaire de compromis entre des contraintes
contradictoires et ignorer ces contraintes rend la discussion sur la
conception vaine.

Oui, on peut présenter des techniques comme solution a des problèmes -- tu
en présentes deux ici -- mais sans le contexte le choix de la meilleure
technique révèle plus les hypothèses de ceux qui en discutent qu'autre
chose.

Sur le fond, toute solution a base de polymorphisme paramétrique est
implementable en terme de polymorphisme d'inclusion, au pris d'une certaine
lourdeur et d'une absence de verification statique de certaines proprietes
certes, mais une fois les schemas d'implementation connus, la traduction
est presque mecanique. L'inverse n'est pas vrai. Cette constation faite,
il est tentant d'ignorer le polymorphisme parametrique (voyez Java a ses
debuts, Go plus recemment) ou, extreme inverse, d'adopter la position de
Joel.

C'est oublier un peu vite que les points de vue sont differents et qu'il
peut y en avoir un plus clair que l'autre suivant le contexte.

C'est aussi oublier un peu vite des contraintes pratiques. Les
implementations courantes des templates en C++ utilisant l'instantiation
gloutonne (et l'abandon d'export n'est pas un facteur qui va changer cet
etat de fait), toute utilisation d'un objet rends l'unite de compilation
contenant cette utilisation dependante de la definition de l'objet plutot
que simplement de sa declaration. Et c'est transitif. Les consequences
sont parfois prohibitives en temps de compilation.

[Joel F]

Tu es loin d'etre le seul. Joel semble atteint de ;a meme malalie:

Je dois etre la phase de dénie alors, vu que je me considére pas comme malade.

L'inverse n'est pas vrai. Cette constation faite,
il est tentant d'ignorer le polymorphisme parametrique (voyez Java a ses
debuts, Go plus recemment) ou, extreme inverse, d'adopter la position de
Joel.

J'ai déjà une telle réputation avec mes 40 pauvres postes ou y a eu des fuites chez les RG ?

[Jean-Marc.Bourguet]

J'ai déjà une telle réputation avec mes 40 pauvres postes ou y a eu des fuites chez les RG ?

Il ne faut pas aller plus loin que le message que j'ai cite.

(Mais il ne faut pas faire partie des RG pour trouver des choses sur quelqu'un qui ne cache pas son nom; et je suis aussi les ML de boost même si je n'y participe pas.)

[Joel F]

Il ne faut pas aller plus loin que le message que j'ai cite.

(Mais il ne faut pas faire partie des RG pour trouver des choses sur quelqu'un qui ne cache pas son nom; et je suis aussi les ML de boost même si je n'y participe pas.)

Certes. Ma remarque se voulait humoristique de toute manière