Discussion :

[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 :

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

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 !

à vous pour le coup de main en tout cas!

[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 ?

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 :

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
#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() );
 
}

[poukill]

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 !

[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.

[poukill]

Je suis complètement d'accord avec toi...

Merci pour le coup de main ...

[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.

[NiamorH]

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.

[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.

[Jean-Marc.Bourguet]

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.

[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).