Je me souviens que lors de mon examen d'embauche, j'avais eu une question
sur un bout de code, avec le temps et après avoir regardé le livre de
Bjarne, je n'ai pas encore vu le bout de code en question dans une
littérature.
class Person {
public:
Person (void);
~Person (void);
};
class Employe : public virtual Person {
public:
Employe (void);
~Employe (void);
};
Que signifie le "public virtual Person" ?
1) Je rend le classe Person virtuelle lors de l'héritage ?
2) Je ne sais vraiment pas.
| Tiens, au fait, ça existe dans d'autres langages que C++, les | templates ?
Generics in Ada, ou presque tous les langages fonctionnelles nodernes. Java et C# ont ajouté un truc mais c'est du sucre syntactique au dessus des fonctions virtuelles. Eiffel.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| Tiens, au fait, ça existe dans d'autres langages que C++, les
| templates ?
Generics in Ada, ou presque tous les langages fonctionnelles nodernes.
Java et C# ont ajouté un truc mais c'est du sucre syntactique au
dessus des fonctions virtuelles. Eiffel.
| Tiens, au fait, ça existe dans d'autres langages que C++, les | templates ?
Generics in Ada, ou presque tous les langages fonctionnelles nodernes. Java et C# ont ajouté un truc mais c'est du sucre syntactique au dessus des fonctions virtuelles. Eiffel.
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| Tiens, au fait, ça existe dans d'autres langages que C++, les | templates ?
Generics in Ada, ou presque tous les langages fonctionnels modernes. Java et C# ont ajouté un truc mais c'est du sucre syntactic au dessus des fonctions virtuelles. Eiffel a des formes générqiues.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| Tiens, au fait, ça existe dans d'autres langages que C++, les
| templates ?
Generics in Ada, ou presque tous les langages fonctionnels modernes.
Java et C# ont ajouté un truc mais c'est du sucre syntactic au
dessus des fonctions virtuelles. Eiffel a des formes générqiues.
| Tiens, au fait, ça existe dans d'autres langages que C++, les | templates ?
Generics in Ada, ou presque tous les langages fonctionnels modernes. Java et C# ont ajouté un truc mais c'est du sucre syntactic au dessus des fonctions virtuelles. Eiffel a des formes générqiues.
-- Gaby
James Kanze
Fabien LE LEZ wrote:
On Thu, 05 May 2005 11:30:08 +0200, James Kanze :
En général, la couleur du fond est une attribute de la classe. On ne va pas en faire une classe exprès pour ça.
En général, oui. Mais si on veut quelque chose de non prévu par le concepteur de la classe (afficher un bitmap en fond à la place d'une couleur unie, par exemple), il faut bien dériver. C'est d'ailleurs tout l'intérêt de la dérivation dans ces hiérarchies de classes : faire quelque chose que l'auteur de la hiérarchie n'avait pas prévu.
Si tu essaies à faire quelque chose que l'auteur n'a pas prévu, ça ne va pas marcher. Si l'auteur remplit le fond avec un couleur solide avant de d'y dessiner ce qu'il doit y dessiner, et qu'il n'a pas prévu l'option de remplacer le fond avec un bitmap, tu es coincé.
Et quand on veut rajouter cette fonctionnalité dans plus d'une classe de la hiérarchie, on a le choix entre l'héritage multiple ou les templates.
Si l'implémentation prévoit une fonction virtuelle pour remplir le fond, l'idée pourrait marcher. La tendance actuelle est vers les délégués -- modèle stratégie, plutôt que modèle template, mais effectivement, si l'implémentation utilise le modèle template pour de dixaines de paramètres différents, des mixins pour les implémenter n'est peut-être pas une mauvaise idée. Tu as raison -- je n'y avais pas pensé. (Les bibliothèques graphiques dont je me suis servi jusqu'ici utilisaient tous le modèle stratégie quand elles voulaient laisser autant de liberté.)
Tiens, au fait, ça existe dans d'autres langages que C++, les templates ?
Modula-3 et Ada avaient tous les deux des génériques bien avant C++.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Thu, 05 May 2005 11:30:08 +0200, James Kanze <kanze@none>:
En général, la couleur du fond est une attribute de la classe.
On ne va pas en faire une classe exprès pour ça.
En général, oui. Mais si on veut quelque chose de non prévu
par le concepteur de la classe (afficher un bitmap en fond à
la place d'une couleur unie, par exemple), il faut bien
dériver. C'est d'ailleurs tout l'intérêt de la dérivation dans
ces hiérarchies de classes : faire quelque chose que l'auteur
de la hiérarchie n'avait pas prévu.
Si tu essaies à faire quelque chose que l'auteur n'a pas prévu,
ça ne va pas marcher. Si l'auteur remplit le fond avec un
couleur solide avant de d'y dessiner ce qu'il doit y dessiner,
et qu'il n'a pas prévu l'option de remplacer le fond avec un
bitmap, tu es coincé.
Et quand on veut rajouter cette fonctionnalité dans plus d'une
classe de la hiérarchie, on a le choix entre l'héritage
multiple ou les templates.
Si l'implémentation prévoit une fonction virtuelle pour remplir
le fond, l'idée pourrait marcher. La tendance actuelle est vers
les délégués -- modèle stratégie, plutôt que modèle template,
mais effectivement, si l'implémentation utilise le modèle
template pour de dixaines de paramètres différents, des mixins
pour les implémenter n'est peut-être pas une mauvaise idée. Tu
as raison -- je n'y avais pas pensé. (Les bibliothèques
graphiques dont je me suis servi jusqu'ici utilisaient tous le
modèle stratégie quand elles voulaient laisser autant de
liberté.)
Tiens, au fait, ça existe dans d'autres langages que C++, les
templates ?
Modula-3 et Ada avaient tous les deux des génériques bien avant
C++.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
En général, la couleur du fond est une attribute de la classe. On ne va pas en faire une classe exprès pour ça.
En général, oui. Mais si on veut quelque chose de non prévu par le concepteur de la classe (afficher un bitmap en fond à la place d'une couleur unie, par exemple), il faut bien dériver. C'est d'ailleurs tout l'intérêt de la dérivation dans ces hiérarchies de classes : faire quelque chose que l'auteur de la hiérarchie n'avait pas prévu.
Si tu essaies à faire quelque chose que l'auteur n'a pas prévu, ça ne va pas marcher. Si l'auteur remplit le fond avec un couleur solide avant de d'y dessiner ce qu'il doit y dessiner, et qu'il n'a pas prévu l'option de remplacer le fond avec un bitmap, tu es coincé.
Et quand on veut rajouter cette fonctionnalité dans plus d'une classe de la hiérarchie, on a le choix entre l'héritage multiple ou les templates.
Si l'implémentation prévoit une fonction virtuelle pour remplir le fond, l'idée pourrait marcher. La tendance actuelle est vers les délégués -- modèle stratégie, plutôt que modèle template, mais effectivement, si l'implémentation utilise le modèle template pour de dixaines de paramètres différents, des mixins pour les implémenter n'est peut-être pas une mauvaise idée. Tu as raison -- je n'y avais pas pensé. (Les bibliothèques graphiques dont je me suis servi jusqu'ici utilisaient tous le modèle stratégie quand elles voulaient laisser autant de liberté.)
Tiens, au fait, ça existe dans d'autres langages que C++, les templates ?
Modula-3 et Ada avaient tous les deux des génériques bien avant C++.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Jean-Marc Bourguet
Fabien LE LEZ writes:
Tiens, au fait, ça existe dans d'autres langages que C++, les templates ?
La généricité faisait partie du cahier des charges -- daté de juin 1978 -- pour le language qui est devenu Ada. Je suppose que c'était donc dans l'air du temps et pas une idée originale du comité qui a écrit le document.
Quelque chose qui à ma connaissance est unique en C++, c'est les spécialisations explicites et donc tout ce que ça permet.
Des languages que je connais assez pour me prononcer sur ce point, seul C++ impose (pas formellement, mais en pratique) une approche où les instantiations ne peuvent pratiquement pas partager de code. Les autres languages (Eiffel, Modula-3, Java également d'après ce que j'ai compris) demandent une approche où le code est partagé (et permettent donc de mettre un template dans une bibliothèque dynamique). Ada est particulier en permettant les deux (surtout pour Ada83 avait même des compilateurs permettant de choisir l'approche désirée générique par générique; pour Ada95 à ma connaissance aucun compilateur ne permet le partage du code bien que les règles ait été pensées pour permettre les deux).
Pour ceux que ça intéresseraient, http://www.adahome.com/History/Steelman/steeltab.htm est une comparaison entre Ada95, C, C++ et Java en prenant comme base le cahier des charges ci-dessus.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
Tiens, au fait, ça existe dans d'autres langages que C++, les
templates ?
La généricité faisait partie du cahier des charges -- daté
de juin 1978 -- pour le language qui est devenu Ada. Je
suppose que c'était donc dans l'air du temps et pas une idée
originale du comité qui a écrit le document.
Quelque chose qui à ma connaissance est unique en C++, c'est
les spécialisations explicites et donc tout ce que ça
permet.
Des languages que je connais assez pour me prononcer sur ce
point, seul C++ impose (pas formellement, mais en pratique)
une approche où les instantiations ne peuvent pratiquement
pas partager de code. Les autres languages (Eiffel,
Modula-3, Java également d'après ce que j'ai compris)
demandent une approche où le code est partagé (et permettent
donc de mettre un template dans une bibliothèque dynamique).
Ada est particulier en permettant les deux (surtout pour
Ada83 avait même des compilateurs permettant de choisir
l'approche désirée générique par générique; pour Ada95 à ma
connaissance aucun compilateur ne permet le partage du code
bien que les règles ait été pensées pour permettre les
deux).
Pour ceux que ça intéresseraient,
http://www.adahome.com/History/Steelman/steeltab.htm
est une comparaison entre Ada95, C, C++ et Java en prenant
comme base le cahier des charges ci-dessus.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Tiens, au fait, ça existe dans d'autres langages que C++, les templates ?
La généricité faisait partie du cahier des charges -- daté de juin 1978 -- pour le language qui est devenu Ada. Je suppose que c'était donc dans l'air du temps et pas une idée originale du comité qui a écrit le document.
Quelque chose qui à ma connaissance est unique en C++, c'est les spécialisations explicites et donc tout ce que ça permet.
Des languages que je connais assez pour me prononcer sur ce point, seul C++ impose (pas formellement, mais en pratique) une approche où les instantiations ne peuvent pratiquement pas partager de code. Les autres languages (Eiffel, Modula-3, Java également d'après ce que j'ai compris) demandent une approche où le code est partagé (et permettent donc de mettre un template dans une bibliothèque dynamique). Ada est particulier en permettant les deux (surtout pour Ada83 avait même des compilateurs permettant de choisir l'approche désirée générique par générique; pour Ada95 à ma connaissance aucun compilateur ne permet le partage du code bien que les règles ait été pensées pour permettre les deux).
Pour ceux que ça intéresseraient, http://www.adahome.com/History/Steelman/steeltab.htm est une comparaison entre Ada95, C, C++ et Java en prenant comme base le cahier des charges ci-dessus.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Fri, 06 May 2005 19:06:23 +0200, James Kanze :
Si l'implémentation prévoit une fonction virtuelle pour remplir le fond, l'idée pourrait marcher.
Je travaille avec les OWL de Borland (spécifique MS-Windows). Il y a bien une fonction Paint() virtuelle, mais c'est une exception : pour la plupart des fonctionnalités, on "intercepte" les messages envoyés par Windows à la fenêtre. Je préfère ne pas te donner tous les détails, tu en ferais des cauchemards cette nuit ;-)
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
On Fri, 06 May 2005 19:06:23 +0200, James Kanze <kanze@none>:
Si l'implémentation prévoit une fonction virtuelle pour remplir
le fond, l'idée pourrait marcher.
Je travaille avec les OWL de Borland (spécifique MS-Windows). Il y a
bien une fonction Paint() virtuelle, mais c'est une exception : pour
la plupart des fonctionnalités, on "intercepte" les messages envoyés
par Windows à la fenêtre. Je préfère ne pas te donner tous les
détails, tu en ferais des cauchemards cette nuit ;-)
--
Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Si l'implémentation prévoit une fonction virtuelle pour remplir le fond, l'idée pourrait marcher.
Je travaille avec les OWL de Borland (spécifique MS-Windows). Il y a bien une fonction Paint() virtuelle, mais c'est une exception : pour la plupart des fonctionnalités, on "intercepte" les messages envoyés par Windows à la fenêtre. Je préfère ne pas te donner tous les détails, tu en ferais des cauchemards cette nuit ;-)
-- Le grand site de la philosophie animale : <http://perso.edulang.com/philo/>
Arnaud Debaene
Samuel Krempp wrote:
que veux-tu dire par 'cas de mixin' ?
Si tu as une interface que tu veux implémenter dans 2 (ou plus) classes concrètes, ces 2 classes ayant une partie de leur implémentation commune, tu peux mettre cette implémentation commune dans une classe "mixin":
class Mixin : public virtual Interface { public: virtual void f() {/*blabla*/} };
class Impl_A : public virtual Interface, public Mixin { public : virtual void g() {/*blabla*/} };
//idem pour Impl_b avec une implémentation de g différente
Arnaud
Samuel Krempp wrote:
que veux-tu dire par 'cas de mixin' ?
Si tu as une interface que tu veux implémenter dans 2 (ou plus) classes
concrètes, ces 2 classes ayant une partie de leur implémentation commune, tu
peux mettre cette implémentation commune dans une classe "mixin":
Si tu as une interface que tu veux implémenter dans 2 (ou plus) classes concrètes, ces 2 classes ayant une partie de leur implémentation commune, tu peux mettre cette implémentation commune dans une classe "mixin":
