Discussion :

[progfou]

Bonjour tout le monde !
J'ai un classe qui contient des méthodes "protected" déclarées ainsi :

Code :

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

1
2
3
  virtual Void F1( UChar *p1, UChar *p2, int n);
...
void F1( short *p1, short *p2, int n);

Ma question est que j'aimerais spécialiser la fonction F1 en fonction d'un paramètre (ici, n) et j'ai pensé aux templates, évidemment.
Ceci dit, le virtual me pose problème !

Comment faire ?
Merci d'avance !

[Charlemagne]

Ce n'est pas possible de faire des fonctions membres à la fois virtuelle et template. C'est con mais c'est comme ça.

Voici 2 suggestions qui peuvent peut-être te convenir:

- une classe template avec des fonctions virtuelles:

Code :

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

1
2
3
4
5
template<class T>
struct A
{
  virtual void f() const;
};

-une fonction template globale "virtuelle":

Code :

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

1
2
struct A { virtual void f() const; };
template<class T> f(const A &a, T x) { ... a.f(); ... }

[progfou]

C'est con effectivement !
Eh bien, merci de ta réponse, ça m'évite de me prendre la tête à essayer de comprendre ce qui ne va pas .

[JolyLoic]

C'est con, mais ça peut se comprendre. Pour implémenter le mécanisme de fonctions virtuelle, on crée généralement un tableau contenant des pointeurs vers toutes celles-ci. Si cette fonction est un template, il y a potentiellement un nombre infini de fonctions virtuelles dans la classe, et le nombre dépend des utilisateurs de celle-ci. Comment donc construire un tel tableau ?

[progfou]

OK, et puis finalement, en creusant, le virtual est superflu ! .
Mais j'aurais au moins compris quelque chose .

[poukill]

OK, et puis finalement, en creusant, le virtual est superflu ! .
Mais j'aurais au moins compris quelque chose .

Sans le virtual, la liaison sera statique et non pas dynamique. Si des personnes héritent plus tard (même beaucoup plus tard) de tes classes, le fait de trouver des fonctions non virtuelles qu'ils auraient bien aimés réimplanter est dommageable...
Evidemment, la liaison statique est toujours au moins aussi rapide que la liaison dynamique!

J'aurai tendance à dire que, moins il y a de virtual, plus le programme s'éloigne de l'orienté objet "pur"...
Dans Java, la liaison est toujours dynamique, au risque c'est vrai, de perde un peu en rapidité.

[JolyLoic]

Je ne connais pas le sujet en question (des noms comme F1, p1... ne sont pas très descriptifs), et donc je ne peux pas juger si l'utilisation d'un lien statique est approprié ou non. Par contre, je récuse le concept de "pureté" comme critère de conception.

Le choix de tout avoir en dynamique me semble généralement une erreur, et introduit une complexité de code, de documentation et de tests énorme (après tout, si une fonction est virtuelle, il faut avoir prévu qu'elle puisse être remplacée, avoir documenté en détail comment elle est sensée être remplacée, et avoir testé que son remplacement fonctionne comme prévu), pour un gain hypothétique et très faible.

[Mat007]

Salut,

Le choix de tout avoir en dynamique me semble généralement une erreur, et introduit une complexité de code, de documentation et de tests énorme (après tout, si une fonction est virtuelle, il faut avoir prévu qu'elle puisse être remplacée, avoir documenté en détail comment elle est sensée être remplacée, et avoir testé que son remplacement fonctionne comme prévu), pour un gain hypothétique et très faible.

En même temps si on fait des tests unitaires (avec des 'mock objects') on tombe très vite dans une vision complètement inverse :
. une classe concrète qui ne dépend que d'interfaces (classe avec uniquement des méthodes virtuelles pures) est une classe facile à tester unitairement
. la flexibilité est énorme : pour ajouter une fonctionnalité il n'y a souvent pas besoin de changer du code, on peut insérer plus facilement des nouveaux objets dans le système (éventuellement en 'proxies', 'décorateurs', etc.. d'objets existants)
. les créations sont centralisées : une classe concrète ne crée aucun objet concret à moins d'être une 'factory' (très peu de code, en général juste un new) ou le 'main' (ou MainWindow ou etc..) qui se contente de créer les objets de haut niveau et de configurer les uns avec les autres
. on aboutit à une vision beaucoup plus haut niveau : on compose des objets entre eux
. les tests sont la documentation utilisateur

Bon je m'embale vite sur ce sujet mais c'est l'idée, et depuis ce déclic ma vie c'est le bonheur

MAT.
(viva TDD !)

[loufoque]

Comment donc construire un tel tableau ?

Il suffit de le construire au moment de l'édition de liens.

[JolyLoic]

On laisse donc tomber la compilation séparée. Ou les bibliothèques dynamiques.

[Charlemagne]

Je comprends le problème pour un compilo de déclarer une fonction comme étant à la fois virtuelle et template.
C'est dommage que ça marche pas.
Mais j'imagine que c'est quand même théoriquement envisageable, mais si j'ai pas trop envie de creuser comment. De toute façon on n'y changera rien.

Perso j'utilise à peine les fonctions virtuelles, je lui préfère de très loin le polymorphisme statique (avec des templates) genre STL. Ca dépend du problème et c'est pas toujours envisageable. Mais je me souviens de d'implémentations de containers (des listes par exemple) basées uniquement sur le polymorphisme virtuel (MFC, java...), je voudrais pour rien au monde troquer la STL contre 100 barils de MFC.

Et puis je ne suis pas d'accord avec ceux qui disent que les fonctions virtuelles perdent un peu en rapidité. Cette affirmation n'est valable que si on considère le temps d'exécution de la fonction. Et ce serait vrai par exemple pour une implémentation d'un GUI, ou le temps d'appel des fonctions est négligeable, et dans ce cas on aurait probablement tord de se priver de l'utilité des fonctions virtuelles.
J'estime qu'il vaut mieux comparer uniquement les temps d'appels aux fonctions. Sans les avoir mesurer, je considère que le temps d'appel des fonctions statiques est nettement plus rapide:
-moins d'instructions nécessaires au processeur
-ne brise pas le pipeline
-pas d'accès mémoire (sur le tableau virtuel)
-potentiellement inline
Bref je considère que pour les calculs numériques les fonctions virtuelles sont à proscrire. Et je m'en passe très bien...