Discussion :

[Natrio]

Bonsoir a tous,

Voila il se trouve que j'ai une fonction dont on ne connetra le type de retour seulement durant sont exécution. J'ai donc après des recherche pensé a fair une fonction template.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
template<typename T> 
T operator() (int i, int j){
 
	if(m_couleur)
		T temp = m_imagesCouleur->operator()(i,j);
	else
		T temp = m_imagesGris->operator()(i,j);
 
	return temp;
 
}

m_imagesCouleur->operator()(i,j); renvoi un unsigned char* et m_imagesGris->operator()(i,j); renvoi un unsigned char.

Donc ce code ne fonctionne pas l'erreur est :

error C2783: 'T images::operator ()(int,int)'*: impossible de déduire l'argument modèle pour 'T'

je pense que malgré le template, il ne parvient pas à définir le type de retour. Exitste-t-il d'autre possibilité? Y a t'il une incompréhenssion de ma part?

Merci pour vos éclairssissement!

[Nogane]

Bonsoir,
Ça ne pourra pas marcher comme ça car le type template doit être connue a la compilation, hors "m_couleur" n'est connu qu'as l'exécution.

Cette opérateur avec juste un if/else est-il vraiment utile alors que de toute façon le code qui l'appel devra aussi gérer ces deux cas?

N'est t'il pas possible que "m_imagesCouleur->operator()" et "m_imagesGris->operator()" renvoie le même type?

[koala01]

Salut,

Déjà, je ne suis pas particulièrement persuadé que l'opérateur parenthèse soit le meilleur choix pour obtenir un char* ou un signed char* au départ de tes images...

En effet, cet opérateur est, classiquement, employé soit comme opérateur de conversion implicite, mais il agira alors comme opérateur de conversion de l'ensemble des données correspondantes de la classe, or, le fait que tu doive lui donner deux entiers en paramètres semble indiquer que ce n'est pas le cas, soit afin de permettre la création d'une "fonction objet" ( un foncteur), ce qui ne semble pas être le cas non plus.

Dés lors, l'utilisation d'une fonction membre "classique" ou d'un foncteur (tiens, justement) semblerait bien plus adaptée

La fonction membre ou le foncteur pourrait de manière cohérente prendre le nom (si j'ai bien compris le but de ton opérateur parenthèse) de colorAt ou quelque chose de fort similaire

De plus, le simple fait qu'une fonction identique (car un opérateur n'est jamais qu'une fonction) renvoie des types différents selon le cas (même si ce n'est que quelque chose signé dans un cas et non signé dans l'autre) semble plaider en faveur de la création de deux types différents, soit héritant d'une base commune, soit parce qu'il s'agirait d'alias de type particulier d'une classe générique identique, mais donc sans relation particulière entre les deux...

Le fait que les données internes de tes images soient de types clairement différents, et que, de ce fait, il y a matière à penser que toutes les fonctions prennent des paramètres ou renvoient des valeurs de type différents tendrait d'ailleurs à faire pencher la balance vers la deuxième possibilité

Mais, si tu ne crée pas une classe de base non template dont laquelle hériterait la classe générique, tu ne pourra de toutes manières pas faire cohabiter des images couleurs et des images en tons de gris car la résolution de type des classes et fonctions génériques se fait au moment de la compilation

Et, comme, pour finir, si tu retire toutes les informations dont le type dépend du fait que l'image est en couleurs ou en niveau de gris, il ne restera sans doute plus grand chose, à part la hauteur et sa largeur, j'en viens presque à me demander si une classe aussi limitée aura le moindre intérêt comme interface commune dont le but serait de permettre de faire cohabiter les deux genres d'images

Bref,si l'idée de passer par la programmation générique représente bel et bien des avantages certains, je ne crois pas qu'il soit opportun de vouloir faire cohabiter dans un même conteneur des images couleurs et des images en tons de gris, et partant, je dirais que le problème se réglera tout seul: soit tu manipule un genre d'image, soit du manipule l'autre, mais, quoi qu'il en soit, tu sera en mesure de déterminer, à un moment donné, le type de valeur que ta fonction va renvoyer

Ceci ne devrait malgré tout pas t'empêcher d'envisager la création de classes génériques pour lesquelles tu fournirais des spécialisations totales selon le genre d'image en cours de traitement, par exemple

[3DArchi]

Salut,
J'aurais tendance à partage l'avis de Koala qu'on pourrait résumer par : problème de conception.

Néanmoins, pour résoudre ton problème, tu peux utiliser Boost.Variant.

[Nogane]

Je suis d'accord aussi avec koala01.

Par contre juste une chose:

même si ce n'est que quelque chose signé dans un cas et non signé dans l'autre

m_imagesCouleur->operator()(i,j); renvoi un unsigned char* et m_imagesGris->operator()(i,j); renvoi un unsigned char.

En fait il ne s'agit pas d'un problème de signé/non signé, mais de pointeur/non pointeur. Je suppose que d'un coté un pixel fait un octet, et de l'autre 3. Ce qui explique que d'un coté on renvoie un char, et de l'autre un pointeur. (Ce ne sont que des suppositions).
Dans cette configuration, renvoyer un pointeur dans les deux cas reste une solution.
(Même si, a bien y réfléchir ça ne change rien au problème de conception)

[Natrio]

En fait il ne s'agit pas d'un problème de signé/non signé, mais de pointeur/non pointeur. Je suppose que d'un coté un pixel fait un octet, et de l'autre 3. Ce qui explique que d'un coté on renvoie un char, et de l'autre un pointeur. (Ce ne sont que des suppositions).
Dans cette configuration, renvoyer un pointeur dans les deux cas reste une solution.
(Même si, a bien y réfléchir ça ne change rien au problème de conception)

Tout à fait Nogane, Il s'agit bien de cela.

L'opérateur () est censé me donner un accès au pixel de coordonné (i,j), dans le cas d'une image grise, cela me renvoi un unsigned char.
Si je rajoute [0 ou 1 ou 2] accède au plan rouge, vert ou bleu d'une image couleur. S'il n'y pas de de [] une image couleur me renvoi unsigned char* sinon un unsigned char.

L'idée de départ était de récupérer les classes faite en cours et de les associer afin de créer un classe qui soit capable de gérer indifféremment une image couleur, ou une image en niveau de gris. Pour l'instant la classe que j'ai créer contient les attributs image couleur et image grise (m_imagesCouleur, m_imagesGris), il n'y a pas d'héritage.
S'il y a défaut de conception est-ce qu'un héritage multiple issue de la classe image grise et couleur pourrait contourner ce problème?

Je sait que j'utilise deux structures de donné différentes, et que en se sens, ce je souhaite faire n'est pas très pertinent, mais je suis tétu!

[koala01]

En fait il ne s'agit pas d'un problème de signé/non signé, mais de pointeur/non pointeur. Je suppose que d'un coté un pixel fait un octet, et de l'autre 3. Ce qui explique que d'un coté on renvoie un char, et de l'autre un pointeur. (Ce ne sont que des suppositions).
Dans cette configuration, renvoyer un pointeur dans les deux cas reste une solution.
(Même si, a bien y réfléchir ça ne change rien au problème de conception)

Au temps pour moi... vu l'heure, à laquelle j'ai répondu, tu m'excusera d'avoir remarqué le signed et pas l'étoile

L'idée de départ était de récupérer les classes faite en cours et de les associer afin de créer un classe qui soit capable de gérer indifféremment une image couleur, ou une image en niveau de gris. Pour l'instant la classe que j'ai créer contient les attributs image couleur et image grise (m_imagesCouleur, m_imagesGris), il n'y a pas d'héritage.

Comme je l'ai indiqué, tu peux envisager de créer une classe template pour la gestion indifférente des images en couleurs ou des images en ton de gris, mais, de toutes manières, tu devra décider à un moment que l'instance de cette classe est destinée à gérer soit l'un, soit l'autre...

S'il y a défaut de conception est-ce qu'un héritage multiple issue de la classe image grise et couleur pourrait contourner ce problème?

Surtout pas malheureux...

L'héritage permet de préciser qu'il est sémantiquement correct de préciser que l'objet dérivé est un objet de la classe de base...

Si tu venais à créer une classe (mettons ImageGreyColor) qui hérite de ImageGris et de ImageCouleur, il y a chaque fois une relation qui n'est absolument pas correcte: une image en ton de gris n'est absolument pas une image en couleurs, et inversément... Le principe de substitution de liskov ne serait absolument pas respecté ici

[3DArchi]

Je plussoie avec Koala. On pourrait presque dire que t'es dans un cas d'école d'approche générique avec les templates.

[Natrio]

Je plussoie avec Koala. On pourrait presque dire que t'es dans un cas d'école d'approche générique avec les templates.

Quand a amoi je ne dirait pas presque mais, c'est un cas d'école....

Et pour causes ces questions font parti de mon projet C++ de cette année.

Bref je vais donc reprendre entièrement cette classe et la réécrire en template. D'après mes lectures et recherche je dirait que grosso-modo l'instenciation de cette future clesse se fera comme ça:

images<ImageGray> MonImageGray;
ou
images<ImageCouleur> MinImageCouleur;

Dnas se cas là plus de problème à la compilation je connaitrai le type de retour.

Une dernière question. Cette future classe ne recevra que deux types (image couleur et images grise) si un idiot met un int cela n'aurai aucun sens... Comment empècher se genre d'usage?

[Goten]

Tu ne peux pas en C++, (enfin si mais par des moyens détourné), mais si il est assez idiot pour faire ça alors laisse le faire, le compilateur le rappellera à l'ordre bien assez tôt.

[Natrio]

Bon je croi que j'ai toutes les informations pour me (re) lancer.

Merci a vous tous, je m'en vais coder!

[Goten]

Je vais quand même préciser :

Vouloir le faire n'est en général pas une bonne idée parce que soit d'un le type introduit dans le template n'est pas compatible avec les opérations que tu lui appliques et dans ce cas là tu auras un message d'erreur, sinon si c'est compatible alors pourquoi pas le laisser faire?
Sinon tu peux vérifier si une classe passé en paramètre fournie tel ou tel paramètre avec BOOST_STATIC_ASSERT, mais c'est a confirmer.