Template et Polymorphisme = contrainte ?

Version imprimable

Bonjour à tous,

Je me pose une petite question existentielle ! :mrgreen:
Est-ce que le fait d'avoir une classe template avec des fonctions virtuelles ajoutent trop de contraintes au client...

Exemple avec cette class Camera:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 template <typename T> class Camera { public: typedef typename T value_type; //Accès au type depuis l'extérieur typedef typename vigra::BasicImage<T> image; //Accès au type depuis l'extérieur Camera(std::string nomCamera); virtual ~Camera() {} Camera (const & Camera); // On interdit la copie virtual image LoadImageByNumber(int number) = 0; virtual image LoadImageByTime(double time); protected: double m_Tech; // Période d'échantillonnage de la caméra const std::string m_NomCamera; };
Le client devra désormais utiliser le polymorphisme, non pas par un simple pointeur Camera *, mais bien par un Camera<T> * ....

Celà représente t-il une contrainte forte ? Trop forte?
Ce que je veux dire par là c'est que l'introduction d'un template est pour moi une souplesse de plus pour un changement éventuel pour la suite... Si c'est vraiment super chiant pour les appelants (il vont devoir tout templater en fait dans l'IHM), alors je laisse tomber... ;)

:merci: d'éclaicir ma lanterne ! :)

01/02/2008, 10h55
babar63

Bonjour, ce n'est que mon avis mais je ne vois pas en quoi cela represente une contrainte. Pour un projet spécifique tu peux toujours utiliser un typedef (e.g : typedef Camera<float> Cameraf) si la notation "dérange". Ensuite ta classe sera réutilisable si tu as besoin d'une camera qui cette fois doit gérer n'importe quel type. Je pense qu'en comparaison de tout ce que peut apporter les templates la notation est peu cher payée... Mais encore une fois ce n'est que mon avis :king:
01/02/2008, 12h44
poukill

OK d'accord. C'est vrai qu'on gagne en souplesse. Mais je me demande si c'est vraiment ce que je cherche. Je m'explique.
Car si je veux quelquechose de dynamique à l'éxécution je suis marron.
Je peux pas avoir un conteneur de Camera<T>, qui mélange double et int par exemple.
01/02/2008, 12h49
poukill

Voilà une citation de Koala qui semble aller dans mon sens. Ou bien alors j'ai rien compris...

Citation:

Envoyé par Koala01

Or le mécanisme meme des template empeche la virtualisation des méthodes (tu pourrait *éventuellement* utiliser le CRTP, par contre mais, en vaut-ce réellement la peine )
01/02/2008, 13h14
babar63

Je le comprend plutot dans le sens ou "est-il vraiment necessaire d'utiliser le polymorphisme sur les templates?" Il y aura toujours des exceptions bien sur mais en regle général je pense que travailler sur un type (float,...) pour un projet spécifique est suffisant. Si vraiment tu as besoin de ce genre de container tu peux toujours definir une classe de base pour caméra et ensuite la stocker dans le container cette classe...
01/02/2008, 13h27
poukill

Camera, c'est déjà ma classe de base abstraite. La faire dériver d'une autre classe ne servirait à rien puisque je ne pourrais alors pas appeller les fonctions membres virtuelles qui m'intéressent (qui elles sont template)
Hum... ça devient embetant tout ça... :koi:
01/02/2008, 13h45
babar63

Oui en effet j'ai sauté une étape dans le code :aie: désolé, dans ce cas non je suppose que tu ne pourra pas avoir de conteneur de ce genre (je ne vois pas vraiment ce qu'est la CRTP donc je peux me tromper). Mais comme tu l'as dit tu gagne en souplesse, maintenant si on retourne la question admettant que tu banisse les templates, qu'est ce que tu y gagnes vraiment?
01/02/2008, 14h00
poukill

http://en.wikipedia.org/wiki/Curious...mplate_Pattern ;)

J'attend juste quelque temps des fois que j'aie une réponse qui soulève un problème que j'avais pas vu ... :roll:
Et après je mettrai :resolu: ;)

Sinon je pourrai toujours templater la fonction en question, et pas la classe:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
class Camera {
public:
	Camera(std::string nomCamera);
	virtual ~Camera() {}
	Camera (const & Camera); // On interdit la copie
 
        template <typename T>
	virtual image<T> LoadImageByNumber(int number) = 0;
        template <typename T>
	virtual image<T> LoadImageByTime(double time);
 
protected:
	double m_Tech; // Période d'échantillonnage de la caméra
	const std::string m_NomCamera;
};

C'est à étudier, j'y avais pas pensé... :oops:

01/02/2008, 14h57
Médinoc

Non, on ne peut pas faire de fonction virtuelle "plus template que sa classe".
01/02/2008, 15h21
poukill

Effectivement... +1 :king:

Code:

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
class CameraBase
{
public:
	virtual image LoadImageByNumber(int number) = 0;
	virtual image LoadImageByTime(double time) = 0;
};
 
template <typename T>
class CameraImpl : public CameraBase
{
public:
	typedef typename T value_type; //Accès au type depuis l'extérieur
	typedef typename vigra::BasicImage<T> image; //Accès au type depuis l'extérieur
 
	CameraImpl (std::string nomCamera);
	virtual ~CameraImpl () {}
	CameraImpl (const & CameraImpl ); // On interdit la copie
 
	virtual image LoadImageByNumber(int number) = 0;
	virtual image LoadImageByTime(double time);
 
protected:
	double m_Tech; // Période d'échantillonnage de la caméra
	const std::string m_NomCamera;
};
 
typedef CameraImpl<float> Camera;

Non ?

03/02/2008, 11h25
babar63

Citation:

Non ?

C'est ce que je pensais aussi :D mais :

Code:

typedef typename vigra::BasicImage<T> image;

image est defini selon un template....

Merci pour le lien poukill vraiment....Curieux ce pattern en effet mais ca a l'air interessant :P
03/02/2008, 12h21
NiamorH

J'ai envie de te dire, et alors ? Ca n'a aucun rapport.

En passant ces 2 typenames sont inutiles à premiere vue.
04/02/2008, 09h13
poukill

Non.

Citation:

Envoyé par NiamorH

J'ai envie de te dire, et alors ? Ca n'a aucun rapport.

Si car la surcharge que tu me proposes, si attirante quelle doit n'est pas valide. Voir l'entrée ICI de la FAQ. La fonction LoadImage revoit une image qui doit dépendre du type en cours. Le type 'image' que tu as utilisé n'était pas valable. ;)

Citation:

En passant ces 2 typenames sont inutiles à premiere vue.

Si si, ils le sont -> voir ICI
Enfin l'utilisation de typename est conseillé. :)

Merci en tous cas de vous pencher sur mon problème, qui n'est, il faut bien le dire, pas si facile que ça à comprendre... :D
04/02/2008, 11h18
NiamorH
Tes deux liens sont identiques, je suppose que tu parlais de ce lien là : http://cpp.developpez.com/faq/cpp/?p...LATES_typename

Mais dans ce cas, je pense que tu te trompes sur l'utilisation de typename.
Citation:
Envoyé par C++ Templates : The Complete Guide

The typename prefix to a name is required when the name :

Appears in a template
Is qualified
Is not used as in a list of base class specifications or in a list of member initializers introducing a constructor definition
Is dependent on a template parameter

Furthermore, the typename prefix is not allowed unless at least the first three previous conditions hold.
Dans ton cas, ces deux typename sont bien inutiles : ils ne respectent pas la condition N°4.
Je suis même étonné que tu compile car typedef typename T value_type; n'est pas qualified (condition 2) et donc ce typename devrait être interdit !

Pour le type image retourné, tu as tout à fait raison, j'étais à la masse. Je regarderais en détail plus tard. Cela poserait un problème de faire une classe de base pour les image que tu retournerais par pointeur ?

Je suis désolé, j'ai du mal à comprendre la question. Les librairies C++ sont maintenant pratiquement toutes templates, sans problème particulier d'utilisation (j'utilise STL, Boost et CGAL, et il n'y a pratiquement rien qui soit non template dans ces libs très courantes).
Faire des conteneurs mixtes se fait classiquement en dérivant d'une classe de base non template. L'appel des fonctions virtuelles marche très bien (je ne comprends pas l'histoire "le mécanisme meme des template empeche la virtualisation des méthodes"). Les méthodes virtuelles sont bien sûr disponible dans les classes template (ou alors de quoi parle-t-on? que vient faire la dérivation du type paramètre dans l'histoire?). Si le type de retour d'une fm template est inconnu dans la classe de base, il suffit d'appliquer la même méthode (type de retour template dérivant aussi d'une classe de base), comme ceci:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 struct image_base { virtual void affiche (void ) const { throw ( "ne pas appeler directement" ); } }; struct camera_base { virtual const image_base& image ( void ) const { throw ( "ne pas appeler directement" ); } }; template <typename T> struct image_derive : public image_base { virtual void affiche (void ) const { cout << "affiche derive(" << typeid ( T ).name() <<")\n"; } }; template <typename T> struct camera_derive : public camera_base { virtual const image_derive<T>& image ( void ) const { return ( img ); } image_derive<T> img; }; int main .. { vector<camera_base *> vb; vb.push_back ( new camera_derive<int>() ); vb.push_back ( new camera_derive<float>() ); vb[0]->image().affiche(); vb[1]->image().affiche(); }
En ce qui me concerne, la classe telle qu'exprimée dans le premier post me conviendrait totalement en tant qu'utilisateur, j'ai bien du mal à voir de quelle limitation réelle on parle dans la totalité de ce fil de discussion. Ou alors le code ci-dessus n'est pas standard? (j'utilise pourtant des choses de ce genre un peu partout en BCB 2007 et VS 2008, on peut pas vraiment parler de compilateur exotique - et de toute façon, je crois bien que dans le standard, un résolution de signature de fonction virtuelle est validée moyennant la covariance par types de base, et non par la correspondance stricte).

04/02/2008, 15h51
poukill

Citation:

Envoyé par NiamorH

Tes deux liens sont identiques, je suppose que tu parlais de ce lien là : http://cpp.developpez.com/faq/cpp/?p...LATES_typename

Mais dans ce cas, je pense que tu te trompes sur l'utilisation de typename.

Efftivement... :oops: Y'en a un sur les deux qui était inutile...

Citation:

Envoyé par ac_wingless

Je suis désolé, j'ai du mal à comprendre la question. Les librairies C++ sont maintenant pratiquement toutes templates, sans problème particulier d'utilisation (j'utilise STL, Boost et CGAL, et il n'y a pratiquement rien qui soit non template dans ces libs très courantes).

Ton code est correct et fonctionne bien. J'utilise la librairie VIGRA qui ne possède pas de classe de base pour les images, tout est templaté ! :mrgreen: Je suis donc coincé pour ce type d'approche, car il me faut un type de retour covariant... :(

De toute façon, je pense que je ne suis pas dans le vrai... Je m'explique :
La classe Camera a pour seule but d'être une classe de base. Les autres classes CameraIR, CameraVisible etc... implémentent les fonctions membres qui vont bien pour aller chercher des images sur un serveur distant.

Les caméras peuvent être monochromatiques, ou bien RGB, ce qui fait donc deux formats très différents! Mais les types sont connus à l'avance ! :aie:
C'est pourquoi j'ai un:

Code:

class CameraVisible : public Camera <vigra::RGB <double> > {...}

et

Code:

class CameraIR : public Camera <vigra::UInt16> {...}

Vais aller réfléchir encore un peu... ;)

Citation:

Efftivement... Y'en a un sur les deux qui était inutile...

Heu... les deux. Le fait que vigra::BasicImage<T> désigne un type de dépend pas du paramètre template T, c'est toujours le cas, il n'y a pas d'ambiguité.
Code:

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 namespace vigra { template <class T> class BasicImage1 { }; } template <class T> class BasicImage2 { }; template <class T> class C { typedef typename vigra::BasicImage1<T> image1; // Inutile mais compile typedef vigra::BasicImage1<T> image2; // Compile //typedef typename BasicImage2<T> image3; // Interdit car pas qualified typedef BasicImage2<T> image4; // Compile }; int main() { C<int> c; }

04/02/2008, 16h54
ac_wingless

Citation:

Envoyé par poukill

J'utilise la librairie VIGRA qui ne possède pas de classe de base pour les images, tout est templaté ! :mrgreen:

Ah d'accord... la technique ci-dessus ne va donc pas marcher directement, il faudrait de l'habillage pas trop beau :( (renvoyer une classe template contenant un vigra::BasicImage<T>, et dérivant d'une base comme dans le post ci-dessus).

Du point de vue du titre de la discussion, je pense que l'utilisation des templates elle-même n'introduit pas de contrainte particulière (cf. technique du post ci-dessus), mais par contre le besoin de conteneurs hétérogènes force à des contorsions qui, tout en étant obligatoires (et donc tolérées) dans certains langages, sont fondamentalement inélégantes.
04/02/2008, 18h05
poukill

Ok NiamorH, je suis pas encore bien calé sur les typename... (va falloir que je me documente encore un peu ;) )

Concernant le sujet de la discussion, je m'aperçois que j'ai effectivement du mal à m'expliquer correctement.
J'aimerai en fait que le client créer une caméra via une Factory, de sorte qu'il soit complètement découplé de toute implémentation (RGB ou pas). Du coup, la question qui tue :

Citation:

Dans quel type de conteneur va t-il stocker le LoadImage() s'il ne connait pas le type ?

:aie:

1er cas : je fixe le format de l'image, 16 bit non signé. Dans ce cas, le client stocke naturellement une Camera * à l'aide d'une fabrique, et la magie du polymorphisme fait le reste : il récupère des images facilement.

2ème cas : je considère que les formats peuvent varier : double, RGB, etc... Et là c'est la cata, c'est la cata....
Comment utilise t-il la Factory ? Comment sait-il quel type est renvoyé? J'imagine qu'avec une classe de trait je pourrai m'en sortir, mais bon j'ai pas encore une super vision du système ! :roll:

:merci: à vous pour le coup de main en tout cas!

Tu peux faire un adapter... mais le design d'origine sans classe de base pour les images est pas terrible effectivement. Quelles sont les méthodes de BasicImage dont tu voudrais te servir par polymorphisme ? Peux-tu donner des exemples ?

Si tu veux faire interagir les images entre elles, les mixer etc., cela risque d'être chaud... Si en revanche tu veux juste faire : pour chaque image, enregistrer sur disque, c'est simple.

As tu pensé à un truc comme ça (y a surement des erreurs, j'ai fait des suppositions) :

Code:

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
#include <string>
#include <algorithm>
#include <vector>
 
using namespace std;
 
namespace vigra
{
  enum ImageType
  {
    RGB8 = 0,
    BW16  = 1
  };
 
  template <int IMAGETYPE>
  class ImageTraits;
 
  template <>
  class ImageTraits<RGB8>
  {
    typedef unsigned char Type;
    enum Infos
    {
      Depth = 3
    };
  };
 
  template <>
  class ImageTraits<BW16>
  {
    typedef unsigned short Type;
    enum Infos
    {
      Depth = 1
    };
  };
 
  template <int IMAGETYPE>
  class BasicImage
  {
    size_t Size() const
    {
      return 64*32; // hauteur * largeur
    }
  };
}
 
template <int IMAGETYPE, template <int> class VIGRAIMAGE >
void EnregistrementImage( string const &, VIGRAIMAGE<IMAGETYPE> const & );
 
class Image
{
public:
  virtual void Enregistrer() = 0;
};
 
template <class VIGRAIMAGE>
class ImageImpl : public Image
{
public:
  virtual void Enregistrer()
  {
    EnregistrementImage( chemin_, img_ );
  }
 
private:
  string chemin_;
  VIGRAIMAGE img_;
};
 
 
template <int IMAGETYPE, template <int> class VIGRAIMAGE >
void EnregistrementImage( string const & chemin, VIGRAIMAGE<IMAGETYPE> const & img )
{
//  (...)
//  file.write( img.Data(), img.Size()*sizeof( typename vigra::ImageTraits<T>::Type )*vigra::ImageTraits<T>::Depth );
}
 
 
struct Enregistrer
{
  template <typename T>
  void operator () ( T t )
  {
    t->Enregistrer();
  }
};
 
int main()
{
  vector<Image*> vec;
  vec.push_back( new ImageImpl<vigra::BasicImage<vigra::RGB8> >() );
  vec.push_back( new ImageImpl<vigra::BasicImage<vigra::BW16> >() );
 
  for_each( vec.begin(), vec.end(), Enregistrer() );
 
//  for_each( vec.begin(), vec.end(), Delete() );
 
}

05/02/2008, 08h25
poukill

Citation:

Envoyé par NiamorH

Tu peux faire un adapter... mais le design d'origine sans classe de base pour les images est pas terrible effectivement. Quelles sont les méthodes de BasicImage dont tu voudrais te servir par polymorphisme ? Peux-tu donner des exemples ?

Bah ça dépend, il utilise donc des template -> polymoprhisme statique. C'est aussi puissant et surtout beaucoup plus rapide. Les pertes de performance sont quasi nulle par rapport à une version C à base de pointeurs...
Aucunes méthodes. J'utilise juste des formats d'images différents
vigra::BasicImage<int> pour quasiment toutes les caméras
vigra::BasicImage<vigra::RGBValue<double> > pour une caméra.

En fait BasicImage est une class Vigra, donc j'y touche pas, elle est très bien. Au travail, je suis responsable de caméras installées sur une platerforme expérimentale. Mon rôle est donc de "fournir" tout ce qu'il faut pour pouvoir rappatrier n'importe quelle image dans un logiciel (à base de WxWidget).

A bien y réfléchir (j'ai déjà un logiciel existant version 1.0), ça va être l'horreur avec des classes templatés alors que je n'utiliserai que RGB et 16 bit non signé. Et encore... le RGB j'en ai qu'une et c'est la moins utilisée. Au pire avec un pattern Adaptateur, je transforme une CameraRGB en Camera normale...

Merci NiamorH pour ton aide, je vais aller au plus simple pour ce coup ci, il faut savoir parfois rebrousser chemin ! ;)

:merci:
05/02/2008, 11h48
NiamorH

Le polymorphisme statique n'est pas fait pour remplacer le polymorphisme dynamique. Ok il va plus vite car il n'y a pas de recherche intermédiaire dans la vtable etc. mais on ne peux pas l'utiliser dans les mêmes conditions. Polymorphisme statique -> application figée une fois compilée, oublie les conteneurs mixtes effectivement.
Si c'est ce que tu souhaitais, tu vas devoir implémenter un système de polymorphisme dynamique, y a pas moyen autrement.
05/02/2008, 13h05
poukill

Je suis complètement d'accord avec toi... 8-)

Merci pour le coup de main ... :ccool:
05/02/2008, 23h08
Alp

Un sujet sur lequel j'ai pas mal réfléchi est la limite polymorphisme statique/dynamique.

Il s'agit dans ton cas de concilier au mieux le polymorphisme statique et le polymorphisme dynamique. C'est à dire disposer d'une hiérarchie de classes polymorphique qui plus est générique.

Voici quelques mots clés : CRTP, Mixin Layers (documents de Smaragdakis), Multi Paradigm Design (thèse + articles + livre de James O. Coplien). Certains sortent un peu du contexte mais n'en demeurent pas moins intéressants.
05/02/2008, 23h58
NiamorH

Citation:

Envoyé par Alp

Un sujet sur lequel j'ai pas mal réfléchi est la limite polymorphisme statique/dynamique.

Peut-être parce que la question n'es pas assez profondément traitée dans des livres comme Modern C++ Design. Quand tu lis le bouquin, tu te dis, c'est cool, je ne pense plus que prog générique... et boum.
06/02/2008, 01h22
Alp

Oui.

Je vais bientôt recevoir Multi Paradigm Design for C++ (http://www.amazon.fr/Multi-Paradigm-.../dp/0201824671) qui traite pas mal ce sujet là parait-il.

A voir donc.

Mais Modern C++ Design, d'un autre côté, remplit son contrat. Il nous fait penser comme il se doit la programmation générique. Mais après, on doit trouver les limites.
06/02/2008, 09h37
Jean-Marc.Bourguet

Citation:

Envoyé par Alp

Un sujet sur lequel j'ai pas mal réfléchi est la limite polymorphisme statique/dynamique.

La difference polymorphisme statique/dynamique est orthogonale(*) a la difference polymorphisme parametrique/d'inclusion et a mon avis moins importante. Le fait qu'en en C++ les deux sont liees et que l'aspect statique/dynamique soit plus facile a voir peut occulter ce fait. Ne pas oublier non plus qu'en C++, le mecanisme des templates est aussi un mecanisme de surcharge -- ce qui en fait la puissance par rapport a d'autres mecanisme de genericite plus pur. Le parallele avec le polymorphisme d'inclusion qui tire aussi sa puissance d'une surcharge (resolue dynamiquement, les fonctions virtuelles) est certain.

(*) Presque. L'interet d'un polymorphisme parametrique dynamique est grand. Celui d'un polymorphisme d'inclusion statique nettement moins.
06/02/2008, 20h27
Alp

Oui c'est en ce sens que c'est puissant une fois que l'on sait se fixer les limites.

A un certain stade, on tend généralement à essayer de paramétrer tout statiquement. Le résultat est qu'on tombe sur un os : on n'arrive plus à mettre en place l'aspect dynamique qu'on a prévu auparavant.

Il y a vraiment pas mal de documents et techniques divers traitant le sujet. J'ai beaucoup apprécié ces lectures, que je n'ai d'ailleurs pas finies, mais j'ai toutefois déjà pas mal appris (merci Luc au passage).