Bon ça devient plus clair :)

C'est bien le même que celui d'austinpower
Vous êtes dans la même classe ? Et tu en es à quel niveau d'étude ?

Bon je vais essayer de t'aider.

Ok sur le principe. mais moi je mettrais x et y en int.
Un pixel correspond quand même à une valeur entière. A moins que le besoin des doubles ne se fasse sentir lors des manipulations. Il faut peut être aussi prévoir des setteurs si les pixels doivent être transformés par les méthodes d'IMage2D.

Non tu as mal lu ton énoncé. c'est pixel qui hérite de couleur. C'est débile mais moins que l'inverse ;)
C'est débile de faire hériter Pixel de couleur. Pixel devrait avoir une couleur comme membre (ce que vous appelez un attribut

C'est quand même terrible ça:

C'est assez culotté de mettre ça dans l'énoncé alors que quand le type écrit Pixel hérite de Couleur, il ne respecte pas son propre principe.
A moins que.... le but de l'exercice soit que l'élève exerce son esprit critique et mettre Couleur en attribut de Pixel au lieu de faire une dérivation à la c..
Donc moi je mettrai Couleur en attribut de Pixel et j'irai quand même demander au prof si j'ai le droit :) Et si je n'ai pas le droit alors je ferai dériver.
Bon nous arrivons à cette fameuse matrice....
En fait maintenant il apparaît clairement qu'il ne s'agit pas d'une matrice au sens mathématique, pour faire des calculs et tout et tout. Ce que l'énoncé appelle matrice, ce n'est fondamentalement qu'un tableau de Pixel. Attention je dis tableau parce que ça dit ce que ça veut dire. Cela n'entraîne pas qu'il faille obligatoirement prendre un tableau pour contenir les pixels.
Je lis dans l'énoncé:

Voilà donc cette histoire de matrice générique. Bon là je regrette, je sais qu'il faut (que l'on doit) respecter les profs. Mais quand même ça veut rien dire cette phrase. Surtout cela n'a rien à voir de près ou de loin avec la généricité comme on peut la coder en C++. Matrice est un tableau de Pixel, point final. Il n'y a rien de générique là dedans.
Alors que comprendre ? Bien que ça ne soit pas de la programmation générique au sens C++, je crois qu'il faut comprendre que quelque soit l'implémentation de Pixel, le programme doit marcher. Mais comme la matrice est un tableau de Pixel on s'en fout là de la généricité. Je crois qu'il faut comprendre en fait que les méthodes de Image2D doivent toujours marcher. Pour cela je crois qu'il faut définir avant tout une classe Pixel abstraite, exposant une interface constante quelle que soit l'implémentation, et que le Pixel dérive de couleur ou pas.
Donc je pense que la première classe à écrire est

class AbstractPixel
{
public:
	virtual int  /* ou double* / getX() =0;
	virtual int getY() =0;
	virtual RGB getRGB() =0;
	virtual ~AbstractPixel(); // peut être important.
};

RGB étant un type à définir. Soit la classe Couleur complète, sois une structure qui contient les valeurs RGB, bref, comme tu voudras.
L'important c'est qu'après tu fais

class Pixel : public AbstractPixel
{
	// implémentation ici
	// dont
public:
	virtual ~Pixel();
};

Et là, quelle que soit l'implémentation, que Pixel dérive aussi de couleur ou qu'il ait un attribut couleur on s'en fout.
Ton programme marchera puisque qu'il fera appel aux méthodes de la classes AbstractPixel. Et du coup on peut dire *par abus de langage* que Matrice est un tableau générique.
Je pense que c'est là que l'énoncé veut en venir.

C'est ok sur le principe, mais pas T**contenu. Pas de généricité comme on l'a dit. Le type est parfaitement contenu c'est un (Abstract)Pixel donc
Pixel** contenu;
ou même mieux
AbstractPixel** contenu
Et là ton contenu est "générique" ;) :lol:

Et toutes ces méthodes appellent les méthodes de AbstractPixel, communes à toutes espèces de Pixel :) Mais il y selon moi quelque chose qui cloche. Voir plus loin.

Excellente remarque. je dois dire que je ne comprends pas non plus et que je la mettrais en attribut si j'avais le choix.

Non. Je ne vois nulle part dans l'énoncé que image 2D soit abstraite. Et je ne vois pas l'intérêt de faire une classe abstraite. Selon moi les implémentations ont leur place directement dans Image2D. Image hérite de Image2D et peut appeler ses méthodes. C'est même là que l'héritage est véritablement justifié. Image EST une Image2D alors que Image A une matrice :)

Ok pour le principe. Attention à ne pas trop mettre de code dans un constructeur. C'est mieux si le constructeur appelle des méthodes. Gaffe aux levées d'exception du genre bad_alloc ou autre.
Lève toi même des exceptions par exemple si le nom de fichier est pas bon. Enfin n'oublie pas de traiter les destructeurs avec soin. Notamment dans Matrice pour libérer la mémoire occupée par le tableau. A moins que tu n'ai droit à la STL, dans ce cas un vector de vector de Pixel pour la matrice c'est sûrement le mieux et le plus simple.
Un vector, ça c'est une *vraie* classe générique ;)

Voilà, yapluka coder :)