[Héritage] Hériter d'une bibliothèque

Version imprimable

Bonjour à tous,

Je travaille actuellement avec la bibliothèque de traitement d'images CImg. Je la trouve très bien et très complète. Cependant, j'aimerai rajouter des fonctions que je code moi-même...
Je pourrai coder directement dans la librairie (sous forme d'un .h) les nouvelles fonctions membres de mon propre cru, mais en cas de mise à jour de la bibliothèque, celà pose évidemment problème.

La solution logique est donc l'héritage. Mais j'ai une question importante à vous poser: comment créer une classe qui "renverrai" tout vers la classe mère?
Suis-je obliger de redéfinir tous les constructeurs dans ma nouvelle classe fille?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #pragma once #include <iostream> #include <string> #include "CImg.h" template <typename T> class Image : public cimg_library::CImg<T> { public: Image(); //Constructeur par défaut Image(std::string nom_image); // Autre constructeur ~Image(); };
Merci à vous ! :D

03/04/2007, 10h12
Matthieu Brucher

C'est là où on voit que le modèle du "tout méthode" a de très grandes limites dans ces cas.
Désolé, je ne crois pas qu'il y ait de méthode simple pour corriger ce souci.
C'est vraiment *** quand on sait qu'on peut simplement décider de mettre tout en fonction libre qui sera ensuite capable de gérer n'importe quel type d'image...
03/04/2007, 14h33
mchk0123

Citation:

Envoyé par poukill

Suis-je obliger de redéfinir tous les constructeurs dans ma nouvelle classe fille?

Pour le constructeur par défaut, ce n'est pas nécessaire (C++ en rajoutera un tout seul). Pour les autres constructeurs oui (mais il y en a tant que ça ?).

Citation:

Envoyé par poukill

comment créer une classe qui "renverrai" tout vers la classe mère?

Là je comprends pas ! ... Tu parles toujours des constructeurs ou des autres méthodes ?

Si c'est des autres méthodes dont tu parles, je ne vois pas le problème puisque si ta classe fille hérite, elle reprend complètement l'ensemble des méthodes de la classe mère sans rien avoir à écrire de plus ?!? ....
03/04/2007, 14h46
poukill

Merci Miles pour ton avis.

Ce que je cherche à faire, c'est rajouter des fonctions membres dans la classe cimg_library::CImg<T> de la bibliothèque CImg...
Je voulais partir sur de l'héritage pour y arriver, en créant donc ma propre classe Image...
Cette classe Image n'a pas besoin d'attributs, mais seulement de nouvelles méthodes implémentées par mes soins.

Je n'ai pas besoin de réimplémenter les méthodes de la classe mère (bien évidemment), mais par contre il va falloir définir tous les constructeurs (au moins une dizaine)... Ca prendra pas tant de temps que ça, mais je cherchais la solution la plus "élégante" pour rajouter des fonctions à cette librairie! ;)

Si vous avez d'autres idées, qui pourraient faire que ça marche mieux, ou différemment, ça serait cool merci... :P
03/04/2007, 14h54
Matthieu Brucher

Sérieusement, la seule manière propre de réaliser ce genre de choses, ce sont des fonctions libres.
CImg est apparu dans le labo lors de notre recherche de nouvelle solution pour le traitement d'images, elle est vite partie, entre autres pour cette raison, une architecture trop fragile.
03/04/2007, 14h57
poukill

Qu'utilises tu alors comme librairie Miles?
03/04/2007, 15h17
Matthieu Brucher

On utilise Vigra maintenant.

si tu veux quand meme hériter de tous les contructeurs, tu dois pouvoir faire un truc dans le genre (pour tous les constructeurs a 1 ou 2 paramètres) :

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
 
 
class PipoTest1
{
 
public:
 
	PipoTest1(int _iA)
	{
	}
 
	PipoTest1(float _fA)
	{
	}
 
	PipoTest1(const string &_sA)
	{
	}
 
};
 
class PipoTest2 : public PipoTest1
{
 
public:
 
	template <class P1> PipoTest2(const P1 &_1):PipoTest1(_1) {}
	template <class P1,class P2> PipoTest2(const P1 &_1,const P2 &_2):PipoTest1(_1,_2) {}
 
};
 
int _tmain(int argc, _TCHAR* argv[])
{
	PipoTest2 kPipo1(1);
	PipoTest2 kPipo2(1.0f);
	PipoTest2 kPipo3("pipo");
}

03/04/2007, 15h25
poukill

Je l'utilise aussi en parallèle pour tout ce qui est labellisation de zones, etc... Mais l'atout indéniable de CImg est le display des images, simple et efficace.
La partie affichage n'est pas le plus facile en C++, alors... :roll:

Juste deux questions Miles:
1) Comment gères-tu l'affichage? (pour ma culture personnelle)
2) Le problème d'héritage sera le même avec Vigra : pour rajouter des fonctions "membres" ça na marchera guère non? Reste que des "fonctions libres"?

Merci à toi.
03/04/2007, 15h37
Matthieu Brucher

1) N'existe pas dans Vigra
2) aucune méthode à rajouter, tout doit être des fonctions libres - je pensais que ça serait évident vu ce que j'ai indiqué avant -
03/04/2007, 17h01
poukill

Citation:

Envoyé par Miles

1) N'existe pas dans Vigra
2) aucune méthode à rajouter, tout doit être des fonctions libres - je pensais que ça serait évident vu ce que j'ai indiqué avant -

C'était évident, mais bon je préférai m'en assurer, la structure de Vigra étant très différente. Je pense toujours avoir besoin de fonctions annexes, et les fonctions libres ne sont pas vraiment une solution élégante dans le code.

Je sais bien qu'il n'existe rien dans Vigra pour l'affichage. Je voulais savoir ce que tu utilisais pour l'affichage graphique! ;)
Je me penche actuellement sur WxWidget.

Merci.
03/04/2007, 17h42
Matthieu Brucher

Citation:

Envoyé par poukill

Je pense toujours avoir besoin de fonctions annexes, et les fonctions libres ne sont pas vraiment une solution élégante dans le code.

Pas uen solution élégante ?? Tu rigoles ? C'est sans doute la solution la plus élégante dans 99% des cas.

Citation:

Envoyé par poukill

Je sais bien qu'il n'existe rien dans Vigra pour l'affichage. Je voulais savoir ce que tu utilisais pour l'affichage graphique! ;)
Je me penche actuellement sur WxWidget.

Je ne m'occupe pas d'affichage, on a un ingé pour ça. Et comme c'est de l'image 3D, ça n'a plus rien à voir.
03/04/2007, 19h44
poukill

Citation:

Envoyé par Miles

Pas uen solution élégante ?? Tu rigoles ? C'est sans doute la solution la plus élégante dans 99% des cas.

Je ne m'occupe pas d'affichage, on a un ingé pour ça. Et comme c'est de l'image 3D, ça n'a plus rien à voir.

Ok d'accord :oops:
Merci pour l'info. Je n'ai malheureusement personne à qui déléguer mon travail...;)
12/04/2007, 12h30
Ronounours

Utilise les 'plugins' de CImg

Il y a un mécanisme exprès pour ajouter tes fonctions directement dans la classe CImg, sans avoir d'héritages à faire : les plug-ins.

"cimg_plugin : This variable tells the library to use a plugin file to add features to the CImg<T> class. Define it with the path of your plugin file, if you want to add member functions to the CImg<T> class, without having to modify directly the "CImg.h" file. An include of the plugin file is performed in the CImg<T> class. If cimg_plugin if not specified (default), no include is done."

Tu peux regarder, il y a des exemples qui montrent comment faire. Efficace et simple.
12/04/2007, 17h05
poukill

Oh, Merci David! 8-)
Je vais y jeter un coup d'oeil !

J'utilise maintenant WxWidget pour l'affichage et interface graphique.
Pour éviter me modifier tous mes programmes, j'avais surchargé les opérateurs << (du std::cout) et la méthode display (vers une fenetre Widget maintenant).

Je peux faire la même chose avec un plugin ?
12/04/2007, 17h19
Matthieu Brucher

Ce hack est bien la preuve d'une erreur de conception bien dommageable :(
16/04/2007, 15h46
Ronounours

Oui tu peux tout à faire, les plug-ins permettent de personnaliser la bibliothèque comme tu le souhaites :
Tu mets ta fonction dans un fichier 'plugin.h', par exemple :

//--- file plug-in.h
int f(const CImg<T>& a) {
return a.size();
}

(mais ca marche aussi avec un operator<<() par exemple)

puis tu définis simplement :

#define cimg_plugin "plug-in.h"
#include "CImg.h"

et maintenant, la fonction f() est une méthode de CImg<T>, que tu peux appeler dans ton programme.

David.
16/04/2007, 15h52
poukill

Ok merci David pour ces précisions... :D

Si j'ai un souci plus grave, j'irai sur le forum CImg...

A+
17/04/2007, 17h02
JolyLoic

Citation:

Envoyé par mchk0123

Pour le constructeur par défaut, ce n'est pas nécessaire (C++ en rajoutera un tout seul).

A partir du moment où un constructeur est défini, le compilateur n'a plus le droit d'en ajouter un par défaut.
17/04/2007, 18h34
mchk0123

Oui effectivement, il ne rajoute plus de constructeur par défaut dans ce cas là.

C'est assez bizarre d'ailleurs ; je ne comprends pas ce qui l'empêcherai de le faire ?
18/04/2007, 10h53
JolyLoic

A partir du moment où l'on défini un constructeur, il n'est absolument pas certain que la classe puisse être correctement initialisée sans spécifier de paramètres complémentaires. Donc on désactive le constructeur par défaut généré automatiquement. Rien n'empêche l'utilisateur d'en ajouter un s'il veut (alors que rien ne permettrai (encore) d'en enlever un).
20/04/2007, 12h22
poukill

Citation:

Envoyé par Miles

Ce hack est bien la preuve d'une erreur de conception bien dommageable :(

Ce "hack" satisfait tout de même au principe "ouvert-fermé" !
Fermé car la library peut-être utilisée tout de suite avec toute ses fonctions.
Ouverte, car d'autres fonctions peuvent être rajoutées, sans modifier l'interface de celle-ci? ;)

Qu'est ce qui te dérange là dedans?
20/04/2007, 12h29
Matthieu Brucher

L'interface _est_ modifiée. Avec un tel système, on peut même ajouter des variables membres, c'est du grand n'importe quoi, tout ça pour tout utiliser comme méthode. Le dernier chapitre de Exceptional C++ Style est dédié à cette horreur et la détruit purement et simplement.
Il serait tout aussi simple d'imposer ces fonctions membres comme étant libres, et on aurait EXACTEMENT la même facilité d'utilisation, en respectant cette fois-ci correctement le principe ouvert-fermé.
Le principe ouvert fermé, ce n'est pas fermé ) utilisable directement et ouvert = on peut ajouter des choses.
Fermé, c'est le fait que la bibliothèque est un tout cohérent qui n'a pas besoin d'être modifié pour ajouter une fonctionalité par exemple : là, ce n'est clairement pas le cas
Ouvert, c'est la facilité d'ajouter une fonctionalité : là, ce n'est à nouveau pas le cas puisqu'il faut modifier la bibliothèque. De plus, pour utiliser les fonctions avec un autre conteneur est impossible. Donc non, cette bibliothèque ne respecte pas, de mon point de vue, le principe ouvert-fermé, mais plutôt son contraire, le principe fermé ouvert.
20/04/2007, 12h55
poukill

ouvert = encore extensible. "Il devrait être possible d'étendre son ensemble d'opérations ou d'ajouter des champs à ses structures de données." B.Meyer
Donc on est sensé pouvoir rajouté des fonctions membres non?

fermé = accessibles à d'autres modules (interface bien définie et stable). En gros, prêt à l'emploi quoi ! :)

Citation:

Envoyé par Miles

De plus, pour utiliser les fonctions avec un autre conteneur est impossible

Ca, je veux bien te croire. Est-ce que tu pourrais me donner un exemple de ce que ça donnerait si c'était le cas? C'est pour que je comprenne le plus que je n'ai pas avec cette bibliothèque!
20/04/2007, 13h12
Matthieu Brucher

Citation:

Envoyé par poukill

ouvert = encore extensible. "Il devrait être possible d'étendre son ensemble d'opérations ou d'ajouter des champs à ses structures de données." B.Meyer
Donc on est sensé pouvoir rajouté des fonctions membres non?

Non, ce n'est pas exactement ça, c'est plus ouvert par héritage et autres, dont les fonctions libres. Le coeur du module n'est pas ouvert, il est fermé et donc non modifiable, toujours d'après Meyer - j'ai le bouquin chez moi ;) -

Citation:

Envoyé par poukill

fermé = accessibles à d'autres modules (interface bien définie et stable). En gros, prêt à l'emploi quoi ! :)

Et justement, avec ce truc, l'interface n'est pas stable et est différente d'un plug-in à un autre, donc non, ce n'est pas fermé.

Citation:

Envoyé par poukill

Ca, je veux bien te croire. Est-ce que tu pourrais me donner un exemple de ce que ça donnerait si c'était le cas? C'est pour que je comprenne le plus que je n'ai pas avec cette bibliothèque!

Par exemple, si les fonctions étaient du type :

Code:

Image::Result traitement(const Image& image)

aucun souci pour utiliser avec une classe fille, ou même avec tout conteneur utilisant la même interface.
20/04/2007, 14h45
poukill

Citation:

Envoyé par Miles

Non, ce n'est pas exactement ça, c'est plus ouvert par héritage et autres, dont les fonctions libres. Le coeur du module n'est pas ouvert, il est fermé et donc non modifiable, toujours d'après Meyer - j'ai le bouquin chez moi ;) -

Euh, le bouquin je l'ai devant moi :) (2 ème édition : p59) Je l'ai cité exactement!

Citation:

Envoyé par Miles

Et justement, avec ce truc, l'interface n'est pas stable et est différente d'un plug-in à un autre, donc non, ce n'est pas fermé.

C'est vrai, mais si moi j'ai écrit un plug-in, que je l'insère dans la bibliothèque, il sera valable tout le temps. Et quand je fourni mes services (ceux des classes que j'ai développées), c'est transparent pour mon client qui utilise mes classes.

Citation:

Envoyé par Miles

Par exemple, si les fonctions étaient du type :

Code:

Image::Result traitement(const Image& image)

aucun souci pour utiliser avec une classe fille, ou même avec tout conteneur utilisant la même interface.

Oui là je suis d'accord avec toi. Tu veux dire que par la manière dont la bibliothèque travaille sur les objets (sur l'instance courante en fait), ça limite la réutilisabilité.
20/04/2007, 16h07
Matthieu Brucher

Citation:

Envoyé par poukill

Euh, le bouquin je l'ai devant moi :) (2 ème édition : p59) Je l'ai cité exactement!

Ne lis pas que le premier paragraphe, regarde en bas de la page, les mécanismes utilisables pour faire ça ne sont pas de modifier la classe elle-même sans quoi il y a clash à plus ou moins long terme.

Citation:

Envoyé par poukill

C'est vrai, mais si moi j'ai écrit un plug-in, que je l'insère dans la bibliothèque, il sera valable tout le temps. Et quand je fourni mes services (ceux des classes que j'ai développées), c'est transparent pour mon client qui utilise mes classes.

Il ne sera valable que pour toi, dans ton contexte et ne sera pas valable pour qqs d'autre qui aura installé la bibliothèque CImg.

Citation:

Envoyé par poukill

Oui là je suis d'accord avec toi. Tu veux dire que par la manière dont la bibliothèque travaille sur les objets (sur l'instance courante en fait), ça limite la réutilisabilité.

Ca limite l'utilisabilité tout court ce mécanisme ! C'est une vraie rustine de m***e, un gros hack pour contourner le fait que la conception originale a été baclée.
20/04/2007, 16h23
poukill
Citation:

Envoyé par Miles

Ne lis pas que le premier paragraphe, regarde en bas de la page, les mécanismes utilisables pour faire ça ne sont pas de modifier la classe elle-même sans quoi il y a clash à plus ou moins long terme.

J'ai lu tout le bouquin !! ;) Oui, je suis d'accord avec toi. Celà dit, le principe ouvert-fermé reste un peu "flou" dans sa définition.

Citation:

Envoyé par Miles

Il ne sera valable que pour toi, dans ton contexte et ne sera pas valable pour qqs d'autre qui aura installé la bibliothèque CImg.

Désolé de batailler, ce n'est pas pour t'embêter, mais bien pour comprendre les mécanismes en jeu.
Non, justement. Si je crée une fichier outils.h:
Code:

1 2 3 4 5 #define cimg_plugin "outils.h" //va activer le plugin dans la bibliothèque #include "CImg.h" // des fonctions membres
N'importe qui possédant la bibliothèque sans mes fichiers va se voir automatiquement rajouter le plug-in lorsqu'il va utiliser mes classes, non?
Si le fichier outils.h fait parti de mon "package"?

Citation:

Envoyé par Miles

Ca limite l'utilisabilité tout court ce mécanisme ! C'est une vraie rustine de m***e, un gros hack pour contourner le fait que la conception originale a été baclée.

Pour ma culture, que manque t-il, ou bien que faudrait-il changer à cette conception pour qu'elle soit correcte?

Merci Miles,
20/04/2007, 16h40
poukill

Je viens de voir que Vigra gérait la conception par contrat...
Je crois que c'est tout à fait ce qu'il me faut:

Citation:

vigra_precondition(PREDICATE, MESSAGE);
vigra_postcondition(PREDICATE, MESSAGE);
vigra_invariant(PREDICATE, MESSAGE);
20/04/2007, 16h48
Matthieu Brucher
Citation:

Envoyé par poukill

J'ai lu tout le bouquin !! ;) Oui, je suis d'accord avec toi. Celà dit, le principe ouvert-fermé reste un peu "flou" dans sa définition.

Non, il est très clair, sinon, dans le bouquin de Shalloway, il en est aussi question, et c'est peut-être plus précis.
Le principe ouvert-fermé indique que tu réutilises un module pour en faire un autre. Ici, tu ne réutilises pas, tu modifies, c'est très clair.
Citation:
Envoyé par poukill

Désolé de batailler, ce n'est pas pour t'embêter, mais bien pour comprendre les mécanismes en jeu.
Non, justement. Si je crée une fichier outils.h:

Code:

1 2 3 4 5 #define cimg_plugin "outils.h" //va activer le plugin dans la bibliothèque #include "CImg.h" // des fonctions membres

N'importe qui possédant la bibliothèque sans mes fichiers va se voir automatiquement rajouter le plug-in lorsqu'il va utiliser mes classes, non?
Si le fichier outils.h fait parti de mon "package"?
Peut-être, mais qui te dit qu'il y aura compatibilité binaire avec une autre bibliothèque compilée de CImg - admettons qu'il y ait une telle bibliothèque, ce qui est possible même si CImg est template, dans le cas d'un algo spécifique - lorsque tu voudras lui donner une de tes images ?

Citation:

Envoyé par poukill

Pour ma culture, que manque t-il, ou bien que faudrait-il changer à cette conception pour qu'elle soit correcte?

Merci Miles,

- Supprimer cette possibilité de plug-in
- Arrêter de vouloir tout avoir en fonction membre, surtout si les fonctions membres sont des traitements
Meyer a une approche très pragmatique de ces choses (simplification volontaire de ma part en 2 catégories, il y en a 3, je crois) :
- si la fonction a besoin d'accéder à des infos internes à la classe -> méthode
- si la fonction n'a pas besoin -> fonction externe.
Ca simplifie le design et ça autorise beaucoup plus de réutilisabilité - ça limite aussi le nombre de méthode d'une classe à redéfinir si on veut remplacer une classe par une autre dans une bibliothèque, si l'interface est réduite au minimum... -
20/04/2007, 17h01
poukill

Citation:

Envoyé par Miles

- Supprimer cette possibilité de plug-in
- Arrêter de vouloir tout avoir en fonction membre, surtout si les fonctions membres sont des traitements
Meyer a une approche très pragmatique de ces choses (simplification volontaire de ma part en 2 catégories, il y en a 3, je crois) :
- si la fonction a besoin d'accéder à des infos internes à la classe -> méthode
- si la fonction n'a pas besoin -> fonction externe.
Ca simplifie le design et ça autorise beaucoup plus de réutilisabilité - ça limite aussi le nombre de méthode d'une classe à redéfinir si on veut remplacer une classe par une autre dans une bibliothèque, si l'interface est réduite au minimum... -

1) Quand tu parles de fontions externes, c'est fonctions libres et/ou fonctions membres d'une AUTRE classe qui traite un cas précis de calcul?

2) Sur le site de Vigra : "It's a novel computer vision library that puts its main emphasize on customizable algorithms and data structures."
Ce que ne fait pas CImg c'est bien ça?
20/04/2007, 17h09
Matthieu Brucher

1) Oui, c'est ça, on s'affranchit complètement de la structure à traiter à partir du moment où elle fournit une certaine interface, c'est exactement le pb que tu as toi.
2) C'est ça, puisqu'on ne peut traiter qu'un seul type de données. Dans Vigra, il existe une classe mère qui est une vue de tout et de n'importe quoi, il suffit de l'utiliser et de faire ce qu'on veut.
20/04/2007, 17h11
poukill

OK Merci Miles ! ;)
Bon week-end.