striiiiiiiiiiiiiiing - Page 39

Kevin Kofler (./1139) :
Sinon, il y a aussi le bon vieux pointeur de fonction, hein.

J'ai proposé ça aussi, mais bon... Ca me semble logique que toutes les icones soient apparentées à la même classe, et que chaque icone soit un objet différent des autres.

GoldenCrystal (./1140) :
De toutes façons quelle que soit la méthode utilisée, faut quand même taper tout le code à un endroit ou à un autre donc je vois pas trop le problème

Exact, question de propreté/maintenance/etc, domaine où je n'ai aucune expérience.

Le pointeur de fonction, ça permet d'avoir une seule classe Icon, pas 10000 classes dérivées. Mais ce n'est qu'une bidouille pour émuler un slot, le concept qu'on cherche vraiment ici.

C'est ce que fait delegate en C#, en plus sûr et pouvant être attaché à une instance de classe en plus de ça.
Maintenant perso j'aime bien l'event model de java aussi, plutôt que passer des pointeurs vers des fonctions, qui paraît plutôt rustre en OO, l'utilisateur a simplement à implémenter une interface 'écouteur' et peut ensuite choisir ce qu'il fait des divers événements dans des méthodes. En plus la classe peut être anonyme () et sous Eclipse générée entièrement en 3 clics.
Celui du C# est pas trop mal, mais on n'a pas assez de contrôle sur la chaîne des objets abonnés à un événement je trouve :/ Dans certains cas on aimerait une hiérarchie de traitement des événements; par exemple si un objet tout en avant de l'écran a reçu et traité un clic, on n'aimerait pas que les autres objets derrière qui s'y seraient également abonnés le reçoivent...

Kevin Kofler (./1142) :
ça permet d'avoir une seule classe Icon, pas 10000 classes dérivées

Et c'est quoi le souçaïe ? Et en C++ pur, c'est quoi l'implémentation qui s'en rapproche le plus ?

Y'a pas de souci.
Dans ton cas les classes Icones devraient être suffisamment petites pour que leur déclaration tienne en une ligne à chaque fois (faut compacter un peu quoi), donc c'est très bien…
Faut pas écouter Kevin qui part dans son délire…

Ce n'est pas un délire, c'est totalement idiot d'avoir une classe différente pour chaque icône, c'est la même classe d'objet (=> une seule classe Icon) avec un paramètre, la méthode appelée en cas de clic => slot ou équivalent (pointeur de fonction, foncteur*, listener** etc.).

* Un foncteur en C++ est une classe qui implémente un operator(). Mais on se retrouve là aussi avec une explosion de classes, à moins que le foncteur ne soit qu'un wrapper autour d'un pointeur de fonction par exemple.
** Style Java. Comme un foncteur, sauf que l'operator() ne s'appelle pas operator(). Même problème que pour le foncteur: bonjour l'explosion de classes!

faux avec les classes anonymes, on n'a besoin que de très peu de code même si le compilateur se démerde (et au final on a un jar, alors bon osef du nb de classes)

J'ai pas bien comrpis le problème, mais je te conseille de regarder les functor.

Oui Kevin, c’est vrai qu’avec des signals/slots ça prend moins de code, mais en attendant c’est pas si grave d’utiliser plusieurs classes juste pour ça…

Oui, il est où le problème du nombre de classe ? La consommation mémoire et cpu ? (mécanismes à mettre en place pour chaque classe toussa)
Pour moi, c'est qu'une question de place dans l'IDE à mes yeux hein

Ah, et au fait, question qui m'a travaillée toute la journée sur mon chantier :
Quelle est la différence entre une méthode normale et son équivalent virtuelle ? La virtuelle a une imlémentation mais peut être redéfinie ?
Quelle est la différence entre une méthode virtuelle et une méthode virtuelle pure ? La virtuelle pure n'a pas d'implémentation et peut (doit ?) être redéfinie ?

Je suis preneur d'un tuto sur la virtualité, vraiment sur le concept, le bouquin que j'ai propose plein d'exmples, mais sans expliquer simplement le concept, par exemple avec un tableau bien clair. Du coup, je ne peux qu'essayer de faire des analogies avec les cas dans lesquels je me trouve, et c'est chiant parce que c'est toujours un peu pifométrique comme manière de faire... Donc si vous avec un lien expliquant ce principe de manière claire et concise, je me précipite.

(ps -> j'avais pas pensé à WP, je vais voir, et vous dirai si c'est suffisant)

la différence concerne le cas où un pointeur vers une classe de base contient l'adresse d'une classe dérivée : dans le cas d'une virtuelle, c'est la méthode du type contenu qui sera appelé, dans une non virtuelle c'est le contenant

class A
{
public:
  virtual void f();
  void g();
};
class B : public A
{
public:
  virtual void f();
  void g();
};


// par pointeur, ça change tout
{
  A* b = new B;
  b->f(); // b::f car b pointe vers B
  b->g(); // a::f car b de type A*
}

// dans le cas de valeurs, pas de surprises
{
  A a;
  B b;
  a.f(); // a::f
  a.g(); // a::g
  b.f(); // b::f
  b.g(); // b::g
}

// les références fonctionnent comme les pointeurs
{
  B b;
  A &a = b;
  a.f(); // b::f
  a.g(); // a::g
}

dans le cas de valeurs, il n'y a pas de type différent pour le conteneur et le contenu donc les virtuelles ne changent rien


une virtuelle pure doit être implémentée par une des classes dérivée avant que tu puisses instancier l'objet
tu n'es pas obligé de l'implémenter directement dans la classe fille, mais ça peut être dans une classe qui hérite de la fille (une classe petite fille)

Ok, merci bien, c'est très clair \o/

Pas mal de trucs percutants ici aussi : http://www.google.fr/search?source=ig&hl=fr&rlz=&=&q=m%C3%A9canisme+des+fonctions+virtuelles&aq=f&aqi=&aql=&oq=&gs_rfai=
Premier lien, je peux pas faire de copier coller pour cause de drm, mais les principes énoncés et encadrés en rouge sont très simples et très clairs, j'apprendrai "non-libre" mais tant pis

protip: toutes les méthodes du java sont virtuelles sauf indication contraire (final), c'est une feature du langage. Juste pour info.

(j'ai édité une 50aines de fois, je sais pas si tu as eu la dernière version )

squalyl -> J'espère que le mécanisme de typage dynamique n'est mis en place que quand nécessaire, sinon boujour les perfs ^^

aze -> ok, j'y retourne, merci bien

Bordel, je viens juste de comprendre une des utilités des classes abstraites/fonctions virtuelles pures : la gestion correcte du polymorphisme

aze (./1155) :
(j'ai édité une 50aines de fois, je sais pas si tu as eu la dernière version )

Peut-être que tu devais éditer encore pour corriger ce genre de chose :

a.f(); // b::f
a.g(); // a::f

Finalement
- il n'y a que les méthodes qu'on compte redéfinir dans des classes filles qu'il faut déclarer virtuelles (et s'il y en a, le destructeur doit l'être aussi).
- Les classes abrstraites ont des méthodes virtuelles pures

Et valà, après on fait la tambouille.

Au fait, il y a des cas où on ne veut pas utiliser le polymorphisme, et donc ne pas déclarer une fonction virtuelle ?

quand t'as pas prévu de classe fille

(sinon en java non c'est pas désactivable, mais ça impacte pas les performances. On cherche toujours si la méthode existe dans la classe de l'objet, et si elle existe pas on cherche dans la superclasse. Y'a pas d'héritage multiple.

Oué, mais s'il n'y a pas de classe fille, il n' y a pas de polymorphisme donc c'est réglé ^^

nsigned int color; }Exemple à la va vite:struct Rectangle { unsigned int left, top, width, height; } struct ColoredRectangle : Rectangle { uCe qui est important c'est pas ce code en lui même, il est moisi (y'a aucun accesseur, constructeur, etc.) mais c'est de chopper l'idée qui va avec…

Je me demande si c’est une bonne idée que des classes comportent de telles limitations intrinsèquement (méthodes non virtuelles). Pour le côté performances c’est une très bonne chose, mais pour l’extensibilité… On ne prévoit pas forcément correctement dès le départ quelles opérations seront susceptibles d’être redéfinies dans des classes filles.

pourquoi ce serait pas un job du compilo, de savoir si une méthode est virtuelle ou pas? il le sait, le compilo, qu'une classe a été étendue et qu'une méthode a été overridée...

Pas forcément, en C++ la compilation séparée ne permet pas de conserver ce type d’information.

ah oui

De toutes façons, c'est au concepteur de l'objet de décider quelle méthode doit être virtuelle ou non, et ça s'arrête là.
Personne d'autre n'a son mot à dire.
Si je décide que mon crocodile ne peut jamais être autre chose que de couleur verte ( if (color.G < Max(color.R, color.B)) throw […]; ) j'ai tout à fait le droit, et je vois pas en quoi ça serait légitime que M. Ducpont vienne changer ça pour que mon croco devienne bleu ou arc-en-ciel…

^^

squalyl (./1164) :
pourquoi ce serait pas un job du compilo, de savoir si une méthode est virtuelle ou pas? il le sait, le compilo, qu'une classe a été étendue et qu'une méthode a été overridée...

Tu peux très bien ne pas vouloir de polymorphisme, auquel cas tu redéfinis une méthode non-virtuelle, là ton compilo te la virtualiserait sans rien te dire.

Folco (./1156) :
squalyl -> J'espère que le mécanisme de typage dynamique n'est mis en place que quand nécessaire, sinon boujour les perfs ^^

C'est toujours mis en oeuvre puisque les méthodes sont virtuelles. Mais ça a un impact négligeable sur les perfs, considère plutôt que le fait qu'une méthode soit virtuelle ou non a un rapport avec la conception, pas les perfs ;-)
./1163> OCP (posté dans un lien à JK). Ce n'est pas forcément souhaitable que les méthodes soient redéfinissables ;-)