'Tu' vois peut etre plein de choses. Je ne connais pas de definition claire de 'prog basee objet', ni de 'orientee objet'. Mais la ref que tu as donne definit des criteres dans lequel C++ n'entre pas.
Les definitions floues donnees sur cette page couvrent des langages comme Visual Basic pour 1) et Self, Slate ou JavaScript pour 2). C'est pas top representatif des langages OO tout ca ;-)
a+, ld.
Marc Boyer wrote:
'Tu' vois peut etre plein de choses. Je ne connais pas de
definition claire de 'prog basee objet', ni de 'orientee objet'.
Mais la ref que tu as donne definit des criteres dans lequel C++
n'entre pas.
Les definitions floues donnees sur cette page couvrent des langages
comme Visual Basic pour 1) et Self, Slate ou JavaScript pour 2). C'est
pas top representatif des langages OO tout ca ;-)
'Tu' vois peut etre plein de choses. Je ne connais pas de definition claire de 'prog basee objet', ni de 'orientee objet'. Mais la ref que tu as donne definit des criteres dans lequel C++ n'entre pas.
Les definitions floues donnees sur cette page couvrent des langages comme Visual Basic pour 1) et Self, Slate ou JavaScript pour 2). C'est pas top representatif des langages OO tout ca ;-)
a+, ld.
Mathias Gaunard
Heuh... Les infos que tu as indique ne s'embarassent pas non plus de cette distinction. On pourrait aussi distinguer fonctionnalite et support. Car bon, avec des pointeurs de fonction, on fait de la POO en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du polymorphisme. Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas partie des concepts clés du C.
Je ne suis pas contre une discussion sur des nuances dans le monde objet, je suis pret a reconnaitre les limites de mes connaissances, mais si en cours de discussion il y a des arguments du genre 'il n'y a pas de polymorphisme dynamique en C++ parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation. Je n'ai jamais prétendu cela. Le fait que les fonctions virtuelles ne soient pas activées par défaut montrent bien l'intention de faire de la programmation orientée objet une fonctionnalité à part.
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Je vais donc répéter. Le programmation orientée objet n'est pas un paradigme clé de C++. La programmation basée objet, si.
Cela est totalement indépendant du fait que C++ permette le premier paradigme ou non.
Heuh... Les infos que tu as indique ne s'embarassent pas non plus
de cette distinction. On pourrait aussi distinguer fonctionnalite et
support. Car bon, avec des pointeurs de fonction, on fait de la POO
en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du
polymorphisme.
Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas
partie des concepts clés du C.
Je ne suis pas contre une discussion sur des nuances dans
le monde objet, je suis pret a reconnaitre les limites de mes
connaissances, mais si en cours de discussion il y a des arguments
du genre 'il n'y a pas de polymorphisme dynamique en C++
parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation.
Je n'ai jamais prétendu cela.
Le fait que les fonctions virtuelles ne soient pas activées par défaut
montrent bien l'intention de faire de la programmation orientée objet
une fonctionnalité à part.
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Je vais donc répéter.
Le programmation orientée objet n'est pas un paradigme clé de C++. La
programmation basée objet, si.
Cela est totalement indépendant du fait que C++ permette le premier
paradigme ou non.
Heuh... Les infos que tu as indique ne s'embarassent pas non plus de cette distinction. On pourrait aussi distinguer fonctionnalite et support. Car bon, avec des pointeurs de fonction, on fait de la POO en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du polymorphisme. Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas partie des concepts clés du C.
Je ne suis pas contre une discussion sur des nuances dans le monde objet, je suis pret a reconnaitre les limites de mes connaissances, mais si en cours de discussion il y a des arguments du genre 'il n'y a pas de polymorphisme dynamique en C++ parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation. Je n'ai jamais prétendu cela. Le fait que les fonctions virtuelles ne soient pas activées par défaut montrent bien l'intention de faire de la programmation orientée objet une fonctionnalité à part.
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Je vais donc répéter. Le programmation orientée objet n'est pas un paradigme clé de C++. La programmation basée objet, si.
Cela est totalement indépendant du fait que C++ permette le premier paradigme ou non.
James Kanze
Sylvain wrote:
Mathias Gaunard wrote on 19/01/2007 01:43:
C'est pourtant explicite : la virtualité, et donc le polymorphisme d'héritage, ne sont pas activés par défaut.
soit.
Il est aussi recommandé de ne pas utiliser les fonctions virtuelles à tort et à travers et de préférer les approches à base de templa tes.
pardon ? c'est recommandé où cette censure ?
Vue la façon qu'il l'a formulé : il est bien recommandé de ne pas utiliser les fonctions virtuelles à tort et à travers. Il est aussi recommandé de ne pas utiliser les templates à tort et à travers. En fait, je dirais même qu'on ne doit rien utiliser à tort et à travers:-).
En général, et pour donner une règle qui dit au moins quelque chose : la solution la plus simple est toujours la meilleur. Utiliser ou des fonctions virtuelles, ou des templates, quand ils n'apportent rien à la solution, est à déconseiller. En particulier, un template qui n'a qu'une seule spécialisation est prèsque toujours une faute. (La même chose ne vaut pas pour des fonctions virtuelles : on peut aussi se servir de l'héritage pour des buts d'encapsulation, par exemple dans des variants de l'idiome du pare-feu de compilation.)
Je dirais aussi que les templates et l'héritage s'adressent en général à des problèmes différents, et c'est plutôt rare qu'on a un choix entre eux. En revanche, dans ces rares cas, je privilège l'héritage, parce que c'est plus souple.
-- James Kanze (GABI Software) mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain wrote:
Mathias Gaunard wrote on 19/01/2007 01:43:
C'est pourtant explicite : la virtualité, et donc le polymorphisme
d'héritage, ne sont pas activés par défaut.
soit.
Il est aussi recommandé de ne pas utiliser les fonctions virtuelles à
tort et à travers et de préférer les approches à base de templa tes.
pardon ? c'est recommandé où cette censure ?
Vue la façon qu'il l'a formulé : il est bien recommandé de ne
pas utiliser les fonctions virtuelles à tort et à travers. Il
est aussi recommandé de ne pas utiliser les templates à tort et
à travers. En fait, je dirais même qu'on ne doit rien utiliser à
tort et à travers:-).
En général, et pour donner une règle qui dit au moins quelque
chose : la solution la plus simple est toujours la meilleur.
Utiliser ou des fonctions virtuelles, ou des templates, quand
ils n'apportent rien à la solution, est à déconseiller. En
particulier, un template qui n'a qu'une seule spécialisation est
prèsque toujours une faute. (La même chose ne vaut pas pour des
fonctions virtuelles : on peut aussi se servir de l'héritage
pour des buts d'encapsulation, par exemple dans des variants de
l'idiome du pare-feu de compilation.)
Je dirais aussi que les templates et l'héritage s'adressent en
général à des problèmes différents, et c'est plutôt rare qu'on a
un choix entre eux. En revanche, dans ces rares cas, je
privilège l'héritage, parce que c'est plus souple.
--
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
C'est pourtant explicite : la virtualité, et donc le polymorphisme d'héritage, ne sont pas activés par défaut.
soit.
Il est aussi recommandé de ne pas utiliser les fonctions virtuelles à tort et à travers et de préférer les approches à base de templa tes.
pardon ? c'est recommandé où cette censure ?
Vue la façon qu'il l'a formulé : il est bien recommandé de ne pas utiliser les fonctions virtuelles à tort et à travers. Il est aussi recommandé de ne pas utiliser les templates à tort et à travers. En fait, je dirais même qu'on ne doit rien utiliser à tort et à travers:-).
En général, et pour donner une règle qui dit au moins quelque chose : la solution la plus simple est toujours la meilleur. Utiliser ou des fonctions virtuelles, ou des templates, quand ils n'apportent rien à la solution, est à déconseiller. En particulier, un template qui n'a qu'une seule spécialisation est prèsque toujours une faute. (La même chose ne vaut pas pour des fonctions virtuelles : on peut aussi se servir de l'héritage pour des buts d'encapsulation, par exemple dans des variants de l'idiome du pare-feu de compilation.)
Je dirais aussi que les templates et l'héritage s'adressent en général à des problèmes différents, et c'est plutôt rare qu'on a un choix entre eux. En revanche, dans ces rares cas, je privilège l'héritage, parce que c'est plus souple.
-- James Kanze (GABI Software) mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau
Mathias Gaunard wrote:
Heuh... Les infos que tu as indique ne s'embarassent pas non plus de cette distinction. On pourrait aussi distinguer fonctionnalite et support. Car bon, avec des pointeurs de fonction, on fait de la POO en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du polymorphisme. Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas partie des concepts clés du C.
Je ne suis pas contre une discussion sur des nuances dans le monde objet, je suis pret a reconnaitre les limites de mes connaissances, mais si en cours de discussion il y a des arguments du genre 'il n'y a pas de polymorphisme dynamique en C++ parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation. Je n'ai jamais prétendu cela. Le fait que les fonctions virtuelles ne soient pas activées par défaut montrent bien l'intention de faire de la programmation orientée objet une fonctionnalité à part.
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Je vais donc répéter. Le programmation orientée objet n'est pas un paradigme clé de C++. La programmation basée objet, si.
Je pense que vous avez une vision tres minimaliste de ce qu'est C++ et que vous melangez les differents types de polymorphisme.
struct A {}; struct B : A {}; void f(A &a) {}
int main() { B b; f(b); return 0; }
Ce code n'a pas de virtual, poutant l'appel f(b) utilise le polymorphisme "implicite" comme vous le qualifiez. Si vous n'en etes pas convaincu, changez "struct B : A" en "class B : A" et ca ne compile plus...
Ensuite la POO ne se restreint pas au polymorphisme. L'encapsulation est probablement le premier concept introduit en POO et certain langages se revendiquent OO a travers leur systeme de module.
a+, ld.
Mathias Gaunard wrote:
Heuh... Les infos que tu as indique ne s'embarassent pas non plus
de cette distinction. On pourrait aussi distinguer fonctionnalite et
support. Car bon, avec des pointeurs de fonction, on fait de la POO
en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du
polymorphisme.
Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas
partie des concepts clés du C.
Je ne suis pas contre une discussion sur des nuances dans
le monde objet, je suis pret a reconnaitre les limites de mes
connaissances, mais si en cours de discussion il y a des arguments
du genre 'il n'y a pas de polymorphisme dynamique en C++
parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation.
Je n'ai jamais prétendu cela.
Le fait que les fonctions virtuelles ne soient pas activées par défaut
montrent bien l'intention de faire de la programmation orientée objet
une fonctionnalité à part.
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Je vais donc répéter.
Le programmation orientée objet n'est pas un paradigme clé de C++. La
programmation basée objet, si.
Je pense que vous avez une vision tres minimaliste de ce qu'est C++ et
que vous melangez les differents types de polymorphisme.
struct A {};
struct B : A {};
void f(A &a) {}
int main()
{
B b;
f(b);
return 0;
}
Ce code n'a pas de virtual, poutant l'appel f(b) utilise le
polymorphisme "implicite" comme vous le qualifiez. Si vous n'en etes pas
convaincu, changez "struct B : A" en "class B : A" et ca ne compile plus...
Ensuite la POO ne se restreint pas au polymorphisme. L'encapsulation est
probablement le premier concept introduit en POO et certain langages se
revendiquent OO a travers leur systeme de module.
Heuh... Les infos que tu as indique ne s'embarassent pas non plus de cette distinction. On pourrait aussi distinguer fonctionnalite et support. Car bon, avec des pointeurs de fonction, on fait de la POO en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du polymorphisme. Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas partie des concepts clés du C.
Je ne suis pas contre une discussion sur des nuances dans le monde objet, je suis pret a reconnaitre les limites de mes connaissances, mais si en cours de discussion il y a des arguments du genre 'il n'y a pas de polymorphisme dynamique en C++ parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation. Je n'ai jamais prétendu cela. Le fait que les fonctions virtuelles ne soient pas activées par défaut montrent bien l'intention de faire de la programmation orientée objet une fonctionnalité à part.
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Je vais donc répéter. Le programmation orientée objet n'est pas un paradigme clé de C++. La programmation basée objet, si.
Je pense que vous avez une vision tres minimaliste de ce qu'est C++ et que vous melangez les differents types de polymorphisme.
struct A {}; struct B : A {}; void f(A &a) {}
int main() { B b; f(b); return 0; }
Ce code n'a pas de virtual, poutant l'appel f(b) utilise le polymorphisme "implicite" comme vous le qualifiez. Si vous n'en etes pas convaincu, changez "struct B : A" en "class B : A" et ca ne compile plus...
Ensuite la POO ne se restreint pas au polymorphisme. L'encapsulation est probablement le premier concept introduit en POO et certain langages se revendiquent OO a travers leur systeme de module.
a+, ld.
Marc Boyer
Le 19-01-2007, Mathias Gaunard a écrit :
Heuh... Les infos que tu as indique ne s'embarassent pas non plus de cette distinction. On pourrait aussi distinguer fonctionnalite et support. Car bon, avec des pointeurs de fonction, on fait de la POO en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du polymorphisme. Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas partie des concepts clés du C.
Je crois qu'il y a la consensus.
Je ne suis pas contre une discussion sur des nuances dans le monde objet, je suis pret a reconnaitre les limites de mes connaissances, mais si en cours de discussion il y a des arguments du genre 'il n'y a pas de polymorphisme dynamique en C++ parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation. Je n'ai jamais prétendu cela.
C'est vrai. Si je reformule mieux, tu dits que (le concept de) la liaison dynamique ne fait pas partie de C++ parce qu'il faut ajouter un mot cle pour l'avoir.
Le fait que les fonctions virtuelles ne soient pas activées par défaut montrent bien l'intention de faire de la programmation orientée objet une fonctionnalité à part.
Ah ?
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Doucement, c'est toi qui a dit que C++ etait 'base objet' et non 'oriente objet', en donnant un ref qui donnait une definition a laquelle C++ ne repond pas (mais C++ sans virtual peut-etre).
Alors ensuite, si on veut discuter des 'intentions' de C++ et non pas de ses fonctionnalites, mieux vaut interroger le DnE que donner de tels arguments.
Je vais donc répéter. Le programmation orientée objet n'est pas un paradigme clé de C++. La programmation basée objet, si.
Je sais a peut pret parler des mecanismes C++. Ses paradigmes, ca commence a devenir plus difficile. Differencer les paradigmes clef des paradigmes secondaire, ca devient plus subtil, et si on commence a argumenter en utilisant l'obligation de mot-clef, ca devient trop lourd.
Cela est totalement indépendant du fait que C++ permette le premier paradigme ou non.
On a pas la meme relation d'independance.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 19-01-2007, Mathias Gaunard <loufoque@remove.gmail.com> a écrit :
Heuh... Les infos que tu as indique ne s'embarassent pas non plus
de cette distinction. On pourrait aussi distinguer fonctionnalite et
support. Car bon, avec des pointeurs de fonction, on fait de la POO
en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du
polymorphisme.
Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas
partie des concepts clés du C.
Je crois qu'il y a la consensus.
Je ne suis pas contre une discussion sur des nuances dans
le monde objet, je suis pret a reconnaitre les limites de mes
connaissances, mais si en cours de discussion il y a des arguments
du genre 'il n'y a pas de polymorphisme dynamique en C++
parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation.
Je n'ai jamais prétendu cela.
C'est vrai. Si je reformule mieux, tu dits que (le concept de) la
liaison dynamique ne fait pas partie de C++ parce qu'il faut
ajouter un mot cle pour l'avoir.
Le fait que les fonctions virtuelles ne soient pas activées par défaut
montrent bien l'intention de faire de la programmation orientée objet
une fonctionnalité à part.
Ah ?
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Doucement, c'est toi qui a dit que C++ etait 'base objet' et non
'oriente objet', en donnant un ref qui donnait une definition a laquelle
C++ ne repond pas (mais C++ sans virtual peut-etre).
Alors ensuite, si on veut discuter des 'intentions' de C++ et non
pas de ses fonctionnalites, mieux vaut interroger le DnE que donner
de tels arguments.
Je vais donc répéter.
Le programmation orientée objet n'est pas un paradigme clé de C++. La
programmation basée objet, si.
Je sais a peut pret parler des mecanismes C++. Ses paradigmes,
ca commence a devenir plus difficile. Differencer les paradigmes clef
des paradigmes secondaire, ca devient plus subtil, et si on commence
a argumenter en utilisant l'obligation de mot-clef, ca devient
trop lourd.
Cela est totalement indépendant du fait que C++ permette le premier
paradigme ou non.
On a pas la meme relation d'independance.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Heuh... Les infos que tu as indique ne s'embarassent pas non plus de cette distinction. On pourrait aussi distinguer fonctionnalite et support. Car bon, avec des pointeurs de fonction, on fait de la POO en C. Donc il y a du polymorphisme en C ?
Bien entendu, C dispose tout comme C++ des fonctionnalités pour faire du polymorphisme. Ça se fait d'ailleurs très bien, même si c'est moins pratique qu'en C++.
Ça ne change pas le fait que la programmation orientée objet ne fait pas partie des concepts clés du C.
Je crois qu'il y a la consensus.
Je ne suis pas contre une discussion sur des nuances dans le monde objet, je suis pret a reconnaitre les limites de mes connaissances, mais si en cours de discussion il y a des arguments du genre 'il n'y a pas de polymorphisme dynamique en C++ parce que ce n'est pas active par defaut', ca va me lasser.
Merci d'arrêter cette diffamation. Je n'ai jamais prétendu cela.
C'est vrai. Si je reformule mieux, tu dits que (le concept de) la liaison dynamique ne fait pas partie de C++ parce qu'il faut ajouter un mot cle pour l'avoir.
Le fait que les fonctions virtuelles ne soient pas activées par défaut montrent bien l'intention de faire de la programmation orientée objet une fonctionnalité à part.
Ah ?
Encore, une fois, tu sembles confondre le paradigme avec le langage.
Doucement, c'est toi qui a dit que C++ etait 'base objet' et non 'oriente objet', en donnant un ref qui donnait une definition a laquelle C++ ne repond pas (mais C++ sans virtual peut-etre).
Alors ensuite, si on veut discuter des 'intentions' de C++ et non pas de ses fonctionnalites, mieux vaut interroger le DnE que donner de tels arguments.
Je vais donc répéter. Le programmation orientée objet n'est pas un paradigme clé de C++. La programmation basée objet, si.
Je sais a peut pret parler des mecanismes C++. Ses paradigmes, ca commence a devenir plus difficile. Differencer les paradigmes clef des paradigmes secondaire, ca devient plus subtil, et si on commence a argumenter en utilisant l'obligation de mot-clef, ca devient trop lourd.
Cela est totalement indépendant du fait que C++ permette le premier paradigme ou non.
On a pas la meme relation d'independance.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Mathias Gaunard
Je sais a peut pret parler des mecanismes C++. Ses paradigmes, ca commence a devenir plus difficile. Differencer les paradigmes clef des paradigmes secondaire, ca devient plus subtil, et si on commence a argumenter en utilisant l'obligation de mot-clef, ca devient trop lourd.
J'utilise pourtant le terme 'clé' depuis le début.
Je sais a peut pret parler des mecanismes C++. Ses paradigmes,
ca commence a devenir plus difficile. Differencer les paradigmes clef
des paradigmes secondaire, ca devient plus subtil, et si on commence
a argumenter en utilisant l'obligation de mot-clef, ca devient
trop lourd.
J'utilise pourtant le terme 'clé' depuis le début.
Je sais a peut pret parler des mecanismes C++. Ses paradigmes, ca commence a devenir plus difficile. Differencer les paradigmes clef des paradigmes secondaire, ca devient plus subtil, et si on commence a argumenter en utilisant l'obligation de mot-clef, ca devient trop lourd.
J'utilise pourtant le terme 'clé' depuis le début.
Sylvain
James Kanze wrote on 19/01/2007 13:37:
[...] Je dirais aussi que les templates et l'héritage s'adressent en général à des problèmes différents, et c'est plutôt rare qu'on a un choix entre eux. En revanche, dans ces rares cas, je privilège l'héritage, parce que c'est plus souple.
je souscris à l'intégralité de ton point. en fait, ma surprise venait de là: déconseiller une approche pour lui préférer quelque chose ne pouvant répondre aux mêmes exigences est surprenant.
Sylvain.
James Kanze wrote on 19/01/2007 13:37:
[...]
Je dirais aussi que les templates et l'héritage s'adressent en
général à des problèmes différents, et c'est plutôt rare qu'on a
un choix entre eux. En revanche, dans ces rares cas, je
privilège l'héritage, parce que c'est plus souple.
je souscris à l'intégralité de ton point.
en fait, ma surprise venait de là: déconseiller une approche pour lui
préférer quelque chose ne pouvant répondre aux mêmes exigences est
surprenant.
[...] Je dirais aussi que les templates et l'héritage s'adressent en général à des problèmes différents, et c'est plutôt rare qu'on a un choix entre eux. En revanche, dans ces rares cas, je privilège l'héritage, parce que c'est plus souple.
je souscris à l'intégralité de ton point. en fait, ma surprise venait de là: déconseiller une approche pour lui préférer quelque chose ne pouvant répondre aux mêmes exigences est surprenant.
Sylvain.
Mathias Gaunard
Ce code n'a pas de virtual, poutant l'appel f(b) utilise le polymorphisme "implicite" comme vous le qualifiez. Si vous n'en etes pas convaincu, changez "struct B : A" en "class B : A" et ca ne compile plus...
L'OBP c'est l'OOP sans l'héritage, et donc sans le polymorphisme.
Quel est donc l'apport de votre commentaire, si ce n'est dire qu'on n'a pas besoin des fonctions virtuelles pour voir apparaître certaines caractéristiques du polymorphisme ?
Ensuite la POO ne se restreint pas au polymorphisme. L'encapsulation est probablement le premier concept introduit en POO et certain langages se revendiquent OO a travers leur systeme de module.
L'encapsulation est une fonctionnalité du OBP, pas du OOP. Ça ne passe pas par l'héritage.
Ce code n'a pas de virtual, poutant l'appel f(b) utilise le
polymorphisme "implicite" comme vous le qualifiez. Si vous n'en etes pas
convaincu, changez "struct B : A" en "class B : A" et ca ne compile plus...
L'OBP c'est l'OOP sans l'héritage, et donc sans le polymorphisme.
Quel est donc l'apport de votre commentaire, si ce n'est dire qu'on n'a
pas besoin des fonctions virtuelles pour voir apparaître certaines
caractéristiques du polymorphisme ?
Ensuite la POO ne se restreint pas au polymorphisme. L'encapsulation est
probablement le premier concept introduit en POO et certain langages se
revendiquent OO a travers leur systeme de module.
L'encapsulation est une fonctionnalité du OBP, pas du OOP.
Ça ne passe pas par l'héritage.
Ce code n'a pas de virtual, poutant l'appel f(b) utilise le polymorphisme "implicite" comme vous le qualifiez. Si vous n'en etes pas convaincu, changez "struct B : A" en "class B : A" et ca ne compile plus...
L'OBP c'est l'OOP sans l'héritage, et donc sans le polymorphisme.
Quel est donc l'apport de votre commentaire, si ce n'est dire qu'on n'a pas besoin des fonctions virtuelles pour voir apparaître certaines caractéristiques du polymorphisme ?
Ensuite la POO ne se restreint pas au polymorphisme. L'encapsulation est probablement le premier concept introduit en POO et certain langages se revendiquent OO a travers leur systeme de module.
L'encapsulation est une fonctionnalité du OBP, pas du OOP. Ça ne passe pas par l'héritage.
Mathias Gaunard
je souscris à l'intégralité de ton point. en fait, ma surprise venait de là: déconseiller une approche pour lui préférer quelque chose ne pouvant répondre aux mêmes exigences est surprenant.
Le polymorphisme peut être utilisé dans presque tous les cas à la place des templates. On n'y perd alors en performance et en type safety.
C'est pour ça que si on peut utiliser les templates à la place, c'est conseillé.
je souscris à l'intégralité de ton point.
en fait, ma surprise venait de là: déconseiller une approche pour lui
préférer quelque chose ne pouvant répondre aux mêmes exigences est
surprenant.
Le polymorphisme peut être utilisé dans presque tous les cas à la place
des templates.
On n'y perd alors en performance et en type safety.
C'est pour ça que si on peut utiliser les templates à la place, c'est
conseillé.
je souscris à l'intégralité de ton point. en fait, ma surprise venait de là: déconseiller une approche pour lui préférer quelque chose ne pouvant répondre aux mêmes exigences est surprenant.
Le polymorphisme peut être utilisé dans presque tous les cas à la place des templates. On n'y perd alors en performance et en type safety.
C'est pour ça que si on peut utiliser les templates à la place, c'est conseillé.
Sylvain
Mathias Gaunard wrote on 21/01/2007 04:13:
je souscris à l'intégralité de ton point. en fait, ma surprise venait de là: déconseiller une approche pour lui préférer quelque chose ne pouvant répondre aux mêmes exigences est surprenant.
Le polymorphisme peut être utilisé dans presque tous les cas à la place des templates.
pour implémenter une String8 vs String16 ? non il n'y a rien de polymorphe ici et un template évitera le code doublonné. pour implémenter une famille de contrôles d'interface ? non, le polymorphisme nécessaire ne pourrait en aucun cas être coder par un template.
je répète après James que ce sont 2 finalités distinctes.
On n'y perd alors en performance et en type safety.
ah oui ? parce que ?????
C'est pour ça que si on peut utiliser les templates à la place, c'est conseillé.
inapplicable (manque totalement de sens!).
Sylvain.
Mathias Gaunard wrote on 21/01/2007 04:13:
je souscris à l'intégralité de ton point.
en fait, ma surprise venait de là: déconseiller une approche pour lui
préférer quelque chose ne pouvant répondre aux mêmes exigences est
surprenant.
Le polymorphisme peut être utilisé dans presque tous les cas à la place
des templates.
pour implémenter une String8 vs String16 ? non il n'y a rien de
polymorphe ici et un template évitera le code doublonné.
pour implémenter une famille de contrôles d'interface ? non, le
polymorphisme nécessaire ne pourrait en aucun cas être coder par un
template.
je répète après James que ce sont 2 finalités distinctes.
On n'y perd alors en performance et en type safety.
ah oui ? parce que ?????
C'est pour ça que si on peut utiliser les templates à la place, c'est
conseillé.
je souscris à l'intégralité de ton point. en fait, ma surprise venait de là: déconseiller une approche pour lui préférer quelque chose ne pouvant répondre aux mêmes exigences est surprenant.
Le polymorphisme peut être utilisé dans presque tous les cas à la place des templates.
pour implémenter une String8 vs String16 ? non il n'y a rien de polymorphe ici et un template évitera le code doublonné. pour implémenter une famille de contrôles d'interface ? non, le polymorphisme nécessaire ne pourrait en aucun cas être coder par un template.
je répète après James que ce sont 2 finalités distinctes.
On n'y perd alors en performance et en type safety.
ah oui ? parce que ?????
C'est pour ça que si on peut utiliser les templates à la place, c'est conseillé.
