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.

[koala01]

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.

Tu es tout pardonné

[camboui]

Je n'aurais peut-être pas dû parler de POO.
En fait je voulais parler de la syntaxe "polymorphique" du C++ qui permet de résoudre certains aspets conceptuels assez facilement. Ce n'est finalement pas parce qu'on écrit une classe avec des méthodes virtuelles qu'on fait de la POO. Si vous avez une autre nomenclature pour cela, je vous écoute.

Sinon, je lis bien vos commentaires. Et vous prêchez presque à un converti

Certes, la POO et la généricité ne s'opposent pas. Cependant, je ne sais plus dans quel faq ou tuto, on y parle de "policies" et il me semble avoir lu qu'on pouvait "simuler" les méthodes virtuelles. Et justement le code présenté dans le premier post en est une illustration en montrant comme faire la même chose suivant l'une ou l'autre manière.

Vous poussez pour la première méthode, j'en prend bonne note.
Et pourtant...
En regardant les iostream, leur concept est fort proche de ce que je présente mais leur implémentation utilise la deuxième approche. Et c'est justement ce que je cherche à éviter. Je trouve dommage de devoir passer au travers de toute une série de méthodes virtuelles lorsque que j'appelle un simple getline()...

[koala01]

En regardant les iostream, leur concept est fort proche de ce que je présente mais leur implémentation utilise la deuxième approche. Et c'est justement ce que je cherche à éviter. Je trouve dommage de devoir passer au travers de toute une série de méthodes virtuelles lorsque que j'appelle un simple getline()...

Ah, non... si tu regarde attentivement les *stream, tu remarquera qu'il s'agit de spécialisation de base template (basic_istream, héritant de basic_ios, pour istream, basic_ostream héritant de... basic_ios pour ostream)

De manière générale et globale, tu n'a strictement aucune fonction virtuelle dans la STL, et la grande majorité des classes et fonctions sont template, voire des typedef de template (std::string, par exemple est un typedef basic_string<char,/* tous les autres */>)

[3DArchi]

Salut,

Certes, la POO et la généricité ne s'opposent pas. Cependant, je ne sais plus dans quel faq ou tuto, on y parle de "policies" et il me semble avoir lu qu'on pouvait "simuler" les méthodes virtuelles. Et justement le code présenté dans le premier post en est une illustration en montrant comme faire la même chose suivant l'une ou l'autre manière.

Comme l'a dit Joel, avec l'héritage et une méthode virtuelle, la résolution est dynamique, donc à l'exécution. Avec les génériques, cette résolution est statique, donc à la compilation. Ce sont donc 2 choses différentes. Pas la peine de mettre du générique si tu ne connais le comportement effectif qu'à l'exécution du programme.
Comme dit David, générique et héritage sont 2 notions différentes qui s'utilisent ensemble ou séparément, mais pas une à la place de l'autre. Il me semble qu'en général on présent l'extension par héritage sur un axe vertical, et l'extension par généricité sur un axe horizontal pour bien montrer l'orthogonalité des 2 concepts.

P.S. :

Code :

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

1
2
3
4
template<class F>
class Traitement: public F
{
public:

Pourquoi hériter ? Pourquoi hériter publiquement ?

[camboui]

Je te retourne la question: que proposes-tu à la place ?

Pour ma part j'ai appliqué ce qui est enseigné ici (2.2. Utilisation avancée) à propos des politiques (ou policies).

[3DArchi]

La première version :

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

ou une composition :

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

Ou à peu de chose la même chose qu'avec ta version 'oo', même si F::lire et F::sauver ne sont pas virtuelles :

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

Ou héritage privé s'il s'agit de bénéficier de l'implémentation :

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

Le générique (et les politiques) ne se substitue pas à la sémantique d'héritage public (EST-UN) et au LSP.

[camboui]

Ah, non... si tu regarde attentivement les *stream, tu remarquera qu'il s'agit de spécialisation de base template (basic_istream, héritant de basic_ios, pour istream, basic_ostream héritant de... basic_ios pour ostream)

De manière générale et globale, tu n'a strictement aucune fonction virtuelle dans la STL, et la grande majorité des classes et fonctions sont template, voire des typedef de template (std::string, par exemple est un typedef basic_string<char,/* tous les autres */>)

Les iostream possèdent un membre de type pointeur sur basic_streambuf<>, et basic_streambuf<> est bourré de méthodes virtuelles. C'est une implémentation similaire que j'ai proposé dans le premier post. Et justement, je cherche à l'éviter car elle est inutile dans 99,9999% des cas.

[koala01]

Les iostream possèdent un membre de type pointeur sur basic_streambuf<>, et basic_streambuf<> est bourré de méthodes virtuelles. C'est une implémentation similaire que j'ai proposé dans le premier post. Et justement, je cherche à l'éviter car elle est inutile dans 99,9999% des cas.

J'ai eu beau regarder, les seules fonctions virtuelles que j'ai trouvée, c'est

• Le destructeur de basic_ios (qui dérive de ios_base)
• le destructeur de ios_base (qui est une classe de base)
• Le destructeur de failure (classe imbriquée dans ios_base dérivant de exception)
• Le destructeur de exception (qui est une classe de base)
• la fonction membre what de failure
• la fonction membre what de exception

J'ai peut être mal cherché, mais de là à dire que "ca regorge" de fonction virtuelles (d'autant plus que leur domaine est chaque fois particulièrement limité), cela me semble un peu exagéré, non

[3DArchi]

Toute la mécanique des streambuffer est en virtuelle. C'est d'ailleurs là que se passe le principale de la gestion du flux (hors formatage) :

imbue
setbuf
seekoff
seekpos
sync
showmanyc
xsgetn
underflow
uflow
pbackfail
xsputn
overflow

[camboui]

Ouf, enfin, on y arrive !
Merci 3DArchi.

koala01, en effet tu as mal cherché

Donc, la question, puisqu'on touche à du concret, les concepteurs des iostream (plus exactement la classe basic_ios) auraient-ils pu écrire tous les streambuf sans méthodes virtuelles ? Auraient-ils pu remplacer le membre pointeur sur streambuf des iostream (basic_ios) par un paramètre template supplémentaire ?
Bien sûr, les méthodes ios_base::rdbuf(...) seraient supprimées, mais qui s'en sert pour changer dynamiquement de streambuf ?

En gros, ceci

Code :

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

1
2
3
4
5
6
7
8
9
10
template<class _Elem,
	class _Traits>
	class basic_ios
		: public ios_base
	{
		...
private:
		...
		basic_streambuf<_Elem, _Traits> > *_sbuf_ptr;// pointer to stream buffer
	};

aurait pu être écrit comme cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11
template<class _Elem,
	class _Traits,
	class _StrBuf=basic_streambuf<_Elem, _Traits> >
	class basic_ios
		: public ios_base
	{
		...
private:
		...
		_StrBuf _sbuf;// stream buffer
	};

[Laurent Gomila]

Non, car changer le type de streambuf d'un flux pendant l'exécution est une option non négligeable.