Pointeur ou pas ? (résolu)

Pointeur ou pas ? (résolu) - C++ - Programmation

Marsh Posté le 06-04-2007 à 16:14:12    

Bonjour,
 
Ayant repris le C++ depuis quelques jours après 2 ans de PHP/JavaScript, j'ai encore un peu de mal à juger de la nécessité ou non d'utiliser des pointeurs dans mon code...
 
J'hésite ici entre deux syntaxes, qui fonctionnent toutes les deux à merveille, mais dont aucune ne me satisfait (j'ai mis le prototype correspondant de la fonction apply dans chaque code) :
 

Code :
  1. RGradient gradient = RGradient(4); // RGradient est une classe
  2. apply(gradient, 0.6); // void apply (G &gradient, float opacity)
  3. apply(gradient, 1);
  4. delete &gradient; // inutile ?


 
ou :
 

Code :
  1. RGradient *gradient = new RGradient(4);
  2. apply(gradient, 0.6); // void apply (G *gradient, float opacity)
  3. apply(gradient, 1);
  4. delete gradient;


 
Que me conseillez-vous ? Un détail qui vous est sûrement apparu en lisant ce code : je ne sais pas si mettre un delete sur une référence a une utilité !
 
Merci d'avance pour vos réponses
 
ZeBrian


Message édité par ZeBrian le 06-04-2007 à 18:52:18
Reply

Marsh Posté le 06-04-2007 à 16:14:12   

Reply

Marsh Posté le 06-04-2007 à 16:18:31    

Dans ton premier exemple, le delete est inutile, puisque ta variable est static et donc détruite en fin de bloc.


---------------
Töp of the plöp
Reply

Marsh Posté le 06-04-2007 à 16:19:29    

Et donc je dois préférer quelle syntaxe ? :)

Reply

Marsh Posté le 06-04-2007 à 16:20:13    

truc qui n'a rien à voir avec le schmillick... si RGradient est une classe, pourquoi ne pas mettre "Apply" comme méthode de la classe ?

Reply

Marsh Posté le 06-04-2007 à 16:20:35    

MagicBuzz a écrit :

truc qui n'a rien à voir avec le schmillick... si RGradient est une classe, pourquoi ne pas mettre "Apply" comme méthode de la classe ?

 

Bah ca depend de la semantique du bidule et de ce que fait la fonction apply.
Masi si effectivemetn apply utilise les données de RGradient, une méthode me parait mieux


Message édité par Joel F le 06-04-2007 à 16:22:24
Reply

Marsh Posté le 06-04-2007 à 16:22:31    

mais pas l'appel au delete !


---------------
Töp of the plöp
Reply

Marsh Posté le 06-04-2007 à 16:22:32    

En fait j'ai simplifié, apply est une fonction membre de la classe "Text".
 
Elle n'accepte en fait pas que les RGradient en argument, mais toutes les classes héritant d'une classe Gradient dont RGradient est justement fille.
 
Pensez-vous que je doive revoir l'organisation de mes classes ?
 
En tout cas merci pour vos réponses si rapides ;)

Reply

Marsh Posté le 06-04-2007 à 16:22:55    

l'édit de fourbe :o


---------------
Töp of the plöp
Reply

Marsh Posté le 06-04-2007 à 16:22:56    

_darkalt3_ a écrit :

mais pas l'appel au delete !


j'avasi pas vu qu'il y avait deux exemples mea culpa ;)

Reply

Marsh Posté le 06-04-2007 à 16:23:31    

je te pardonne :o


---------------
Töp of the plöp
Reply

Marsh Posté le 06-04-2007 à 16:23:31   

Reply

Marsh Posté le 06-04-2007 à 16:23:43    

merki [:dawa]

Reply

Marsh Posté le 06-04-2007 à 16:24:16    

ZeBrian a écrit :

Et donc je dois préférer quelle syntaxe ? :)


la plus simple.


---------------
Töp of the plöp
Reply

Marsh Posté le 06-04-2007 à 16:24:28    

Donc, Apply va se retrouver en méthode dans ta classe abstraire Gradient, afin d'être disponible dans RGradient et toutes ses copines :) (enfin, moi je ferais comme ça)


Message édité par MagicBuzz le 06-04-2007 à 16:24:39
Reply

Marsh Posté le 06-04-2007 à 16:26:56    

sauf que :

 
ZeBrian a écrit :

apply est une fonction membre de la classe "Text".

 

néanmoins, je verrasi bien apply méthode abstraite de Gradient & co et qui prends ds Text en paramétres.


Message édité par Joel F le 06-04-2007 à 16:27:27
Reply

Marsh Posté le 06-04-2007 à 16:29:54    

Je vais expliquer un peu mieux ce que font mes classes et mes fonctions, car je ne suis pas convaincu de ton organisation MagicBuzz ;)
 
Déjà, l'objectif de l'ensemble : permettre d'écrire un texte sans crénelage sur une image, avec possibilité d'avoir non pas une couleur unie mais un dégradé vertical dans le texte
 
En créant un objet de la classe Text, on pourra dessiner plusieurs fois le texte avec des dégradés différents. Je ne crée pas un nouvel objet Text à chaque fois car pour une même chaîne et des couleurs différentes, il y a pas mal de calculs préliminaires communs permettant par exemple d'avoir un texte anticrénelé.
 
Après avoir créé un dégradé grâce à la classe RGradient, j'appelle donc la fonction membre apply de mon objet Text en lui fournissant le dégradé : ainsi, je pourrai utiliser plusieurs fois un même objet Text pour des couleurs différentes !
 
Je ne suis pas sûr d'avoir été clair, mais j'ai fait de mon mieux :)
 
Edit: Joel F  : je veux aussi pouvoir par exemple "tapisser" mon texte avec une autre image qu'un dégradé, c'est pourquoi mettre la fonction apply dans la classe Gradient me semble un peu inapproprié...

Message cité 1 fois
Message édité par ZeBrian le 06-04-2007 à 16:32:21
Reply

Marsh Posté le 06-04-2007 à 16:35:21    

ZeBrian a écrit :


Déjà, l'objectif de l'ensemble : permettre d'écrire un texte sans crénelage sur une image, avec possibilité d'avoir non pas une couleur unie mais un dégradé vertical dans le texte
 
En créant un objet de la classe Text, on pourra dessiner plusieurs fois le texte avec des dégradés différents. Je ne crée pas un nouvel objet Text à chaque fois car pour une même chaîne et des couleurs différentes, il y a pas mal de calculs préliminaires communs permettant par exemple d'avoir un texte anticrénelé.
 
Après avoir créé un dégradé grâce à la classe RGradient, j'appelle donc la fonction membre apply de mon objet Text en lui fournissant le dégradé : ainsi, je pourrai utiliser plusieurs fois un même objet Text pour des couleurs différentes !
 
Je ne suis pas sûr d'avoir été clair, mais j'ai fait de mon mieux :)
 
je veux aussi pouvoir par exemple "tapisser" mon texte avec une autre image qu'un dégradé, c'est pourquoi mettre la fonction apply dans la classe Gradient me semble un peu inapproprié...


 
Donc en gros :
- ta classe Texte contient le texte à afficher et les différents "effets"
- RGradient est un effet comm un autre
- tu as d'autres classes pour d'autres effets ?
 
donc ouais apply en méthode de Text est pas mal. Ensuite tout tes effets (gradients etc) devraient hérité de Effect pour obtenir :
 
Text::apply(Effect* e)
 
j'ai bien compris ?

Reply

Marsh Posté le 06-04-2007 à 16:38:02    

dans ce cas, Effect.Apply(Text* t) me semble plus approprié, puisque chaque surcharge de Apply() ne dépend que du type de l'effect, et non du Text : du coup, dans Text, tu as du code spécifique à chaque dérivé de Effect, tandis que chaque dérivés de Effect pourrait contenir un Apply dédié, ne faisant référence qu'à un type de Text (je suis clair là ?)

Reply

Marsh Posté le 06-04-2007 à 16:38:46    

Je crois bien que c'est ça en effet :D
 
Par contre, j'ai utilisé un template pour pouvoir appeler ma fonction apply sur des classes héritant de Gradient :
 

Code :
  1. template <typename G> void apply (G &gradient, float opacity);


 
En effet, la syntaxe suivante ne fonctionnait pas :

Code :
  1. void apply (Gradient &gradient, float opacity);


 
Avec ta syntaxe utilisant un pointeur, cela fonctionnerait donc ? J'essaye de suite !
 
Edit : MagicBuzz : En fait, toutes les classes dérivant de Gradient (alias Effect) disposent de la même fonction virtuelle getColor(x, y) qui rend leur utilisation exactement similaire aux "yeux" de la fonction Text::apply ! C'est pourquoi reprogrammer la fonction apply dans la classe mère Effect me semble moins adapté...


Message édité par ZeBrian le 06-04-2007 à 16:41:38
Reply

Marsh Posté le 06-04-2007 à 16:45:42    

J'ai maintenant un problème de "vtable" à la compilation, dû apparemment au code suivant :

Code :
  1. class Gradient {
  2. protected:
  3.  int dir;
  4.  int size;
  5.  vector<int*> pixels;
  6. public:
  7.  vector<GradientKey> anchors;
  8.  Gradient (int dir, vector<GradientKey> anchors, int size = 0);
  9.  virtual int * getColor (int x, int y);
  10. };
  11. class RGradient : public Gradient {
  12. public:
  13.  RGradient (int dir, vector<GradientKey> anchors, int size = 0);
  14.  int * getColor (int x, int y);
  15. };


 
Y a-t-il une explication (ou carrément une solution ?) à ce petit désagrément ? '^^
 
En tout cas, j'apprécie beaucoup votre aide ! :jap:


Message édité par ZeBrian le 06-04-2007 à 16:47:04
Reply

Marsh Posté le 06-04-2007 à 16:48:08    

quelle est l'erreur exactement ?


---------------
Töp of the plöp
Reply

Marsh Posté le 06-04-2007 à 16:49:26    

[Linker error] undefined reference to 'vtable for RGradient'
[Linker error] undefined reference to 'vtable for Gradient'
 
Apparemment, c'est une erreur propre à G++...

Reply

Marsh Posté le 06-04-2007 à 16:50:00    

et le destructeur virtuel (bordel) ?!

Reply

Marsh Posté le 06-04-2007 à 16:51:15    

OK je vais me renseigner sur ce sujet, c'est vrai qu'au niveau des fonctions virtuelles et des destructeurs je suis encore assez bourrin...
 
Je vous recontacte dès que j'ai corrigé :)
 
EDIT : En fait, je ne comprends pas l'intérêt du destructeur virtuel dans mon cas :whistle:  
 
Voudrais-tu si possible m'orienter vers des articles traitant du sujet ? Il se trouve que j'ai prêté ma bible du C++ et que j'ai un peu du mal à la récupérer :D


Message édité par ZeBrian le 06-04-2007 à 17:04:11
Reply

Marsh Posté le 06-04-2007 à 18:11:19    

Voilà, j'ai corrigé... En fait c'était qu'auparavant je n'avais pas défini la fonction getColor dans la classe Gradient et que mon cher ami Dev-C++ ne prenait pas en compte les changements sur le header !
 
Donc j'ai tout corrigé merci beaucoup à tous :D
 
PS : Je n'ai même pas eu besoin de définir un destructeur virtuel...


Message édité par ZeBrian le 06-04-2007 à 18:11:50
Reply

Marsh Posté le 06-04-2007 à 18:14:01    

_darkalt3_ a écrit :

Dans ton premier exemple, le delete est inutile, puisque ta variable est static et donc détruite en fin de bloc.


Si la variable est - de classe de stockage - static, elle n'est pas détruite en fin de bloc.
Quoi qu'il en soit, que la variable soit static ou automatic, invoquer delete sur son adresse est une erreur.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed