Pertinence des concepts objet avec C++

Fabien LE LEZ <gramster@gramster.com> writes:

Bon, ben tant pis pour l'OP, mais je crois que je vais continuer à
faire comme je le sens, sans me préoccuper de savoir si c'est de la
POO ou pas ;-)

Employer les techniques adaptées à son problème sans trop se soucier
de l'étiquette qu'on peut ou pas leur donner est une solution
nettement meilleure que de ne pas employer une technique parce que des
allatoyas ont décidés qu'elle était contraire à l'étiquette que l'on
désire ou que se contraindre à utiliser une technique parce qu'elle
porte la bonne étiquette.

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

Jean-Marc Bourguet wrote:

Fabien LE LEZ <gramster@gramster.com> writes:

On 22 Jan 2004 02:02:44 -0800, kanze@gabi-soft.fr wrote:

Je dirais même que l'apport le plus important, ce n'est pas l'OO, mais
l'encapsulation -- la partie privée d'une classe et les fonctions
membres.

Euh... Cela ne fait-il pas partie de l'OO ?

Non. (De même la généricité n'en fait pas partie.)

C'est à dire que pour toi, la généricité est dynamique
et que tu ne fait pas une distinction polymorphisme
dynamique (héritage) et polymorphisme statique (généricité) ?

Marc Boyer
PS: fu2 fco
--
Lying for having sex or lying for making war? Trust US presidents :-(

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

Jean-Marc Bourguet wrote:

Fabien LE LEZ <gramster@gramster.com> writes:

On 22 Jan 2004 02:02:44 -0800, kanze@gabi-soft.fr wrote:

Je dirais même que l'apport le plus important, ce n'est pas l'OO, mais
l'encapsulation -- la partie privée d'une classe et les fonctions
membres.

Euh... Cela ne fait-il pas partie de l'OO ?

Non. (De même la généricité n'en fait pas partie.)

C'est à dire que pour toi, la généricité est dynamique et que tu
ne fait pas une distinction polymorphisme dynamique (héritage) et
polymorphisme statique (généricité) ?

L'aspect statique ou dynamique me semble complement independant. Je
peux concervoir un langage ou tout est dynamique ou tout statique
(mais bien plus contraint). En ce qui concerne le polymorphisme de
substitution -- l'heritage n'est qu'un moyen de l'obtenir -- la
version C++ me semble parmis les plus statiques possibles sans
contraintes redihibitives.

La difference entre polymorphisme de substitution et polymorphisme
parametrique est que les operations sur les parametres sont implicites
dans le premier (elles sont deduites du type) et explicite dans le
second.

La situation en C++ est compliquee parce que les templates ont aussi
un aspect substitutionnel -- et un aspect ad hoc d'ailleurs -- qui
sert souvent: on ne passe pas souvent les operations possibles
explicitement (et les traits sont souvent utilises quand on le fait
pour retrouver de l'implicite).

Marc Boyer
PS: fu2 fco
(fclc++ conserve)

--
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

Jean-Marc Bourguet wrote:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

C'est à dire que pour toi, la généricité est dynamique et que tu
ne fait pas une distinction polymorphisme dynamique (héritage) et
polymorphisme statique (généricité) ?

L'aspect statique ou dynamique me semble complement independant. Je
peux concervoir un langage ou tout est dynamique ou tout statique
(mais bien plus contraint). En ce qui concerne le polymorphisme de
substitution -- l'heritage n'est qu'un moyen de l'obtenir -- la
version C++ me semble parmis les plus statiques possibles sans
contraintes redihibitives.

C'est à dire que tu ne vois pas la généricité C++ comme
un moyen de faire du polymorphisme de substitution.

La difference entre polymorphisme de substitution et polymorphisme
parametrique est que les operations sur les parametres sont implicites
dans le premier (elles sont deduites du type) et explicite dans le
second.

Je suis pas bien sur de comprendre ton argumentation.
Pour moi, l'héritage C++/Java/Eiffel fait un polymorphisme
de substitution dans lequel les parametres sont explicites,
puisque donné par le typage que le programmeur doit expliciter.

class X { void foo(); };
class XX : public X {};
class Y { void foo(); };

Si j'écris une fonction qui a besoin que son argument
possède une méthode foo, avec l'héritage, je dois donner
un type (*X ou &X) et seules les classes descendant
explicitement de X pourront être paramêtre.
Alors qu'avec un template, ce sera implicite.

Non ?

La situation en C++ est compliquee parce que les templates ont aussi
un aspect substitutionnel -- et un aspect ad hoc d'ailleurs -- qui
sert souvent: on ne passe pas souvent les operations possibles
explicitement (et les traits sont souvent utilises quand on le fait
pour retrouver de l'implicite).

Oui, pour moi, il y a deux polymorphismes en C++, un dynamique
(mais qui possède des aspects statiques), l'héritage,
et un statique, les templates.
Dans cette approche, SmallTalk est purement dynamique.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Jean-Jacques Puel wrote:

Bonjour,

Après un rapide sondage pour ma culture personnelle sur fro, il apparait que
les spécialistes de l'objet rejettent le langage C++ dont les concepts leur
paraissent aberrants. En gros, il affirment que C++ n'est qu'un patch du
langage C afin de le rendre bancalement OO.
Cela m'embête un peu car je connais bien le langage C et il me semble que
l'apprentissage du C++ aurait été de ce fait facilité.
Je tiens absolument à apprendre un langage objet, mais je désire aussi que
celui ci me permette d'appréhender de façon claire et exhaustive l'ensemble
des concepts objet.
Eux me conseillent plutot Smalltalk ou Python, mais cela s'éloigne de ce que
je connais déjà et ne semble pas hyper répandu.

Si tu viens du C et que tu veux essayer Smalltalk, tu peux essayer
Objective-C. C'est un bon compromis qui utilise la syntaxe du C et
implemente le dynamic binding comme Smalltalk. Comme tous les langages,
il a ses avantages et ses inconvenients.

a+, ld.

Marc Boyer wrote:

Jean-Marc Bourguet wrote:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

C'est à dire que pour toi, la généricité est dynamique et que tu
ne fait pas une distinction polymorphisme dynamique (héritage) et
polymorphisme statique (généricité) ?

L'aspect statique ou dynamique me semble complement independant. Je
peux concervoir un langage ou tout est dynamique ou tout statique
(mais bien plus contraint). En ce qui concerne le polymorphisme de
substitution -- l'heritage n'est qu'un moyen de l'obtenir -- la
version C++ me semble parmis les plus statiques possibles sans
contraintes redihibitives.

C'est à dire que tu ne vois pas la généricité C++ comme
un moyen de faire du polymorphisme de substitution.

La difference entre polymorphisme de substitution et polymorphisme
parametrique est que les operations sur les parametres sont implicites
dans le premier (elles sont deduites du type) et explicite dans le
second.

Je suis pas bien sur de comprendre ton argumentation.
Pour moi, l'héritage C++/Java/Eiffel fait un polymorphisme
de substitution dans lequel les parametres sont explicites,
puisque donné par le typage que le programmeur doit expliciter.

class X { void foo(); };
class XX : public X {};
class Y { void foo(); };

Si j'écris une fonction qui a besoin que son argument
possède une méthode foo, avec l'héritage, je dois donner
un type (*X ou &X) et seules les classes descendant
explicitement de X pourront être paramêtre.
Alors qu'avec un template, ce sera implicite.

Non ?

La situation en C++ est compliquee parce que les templates ont aussi
un aspect substitutionnel -- et un aspect ad hoc d'ailleurs -- qui
sert souvent: on ne passe pas souvent les operations possibles
explicitement (et les traits sont souvent utilises quand on le fait
pour retrouver de l'implicite).

Oui, pour moi, il y a deux polymorphismes en C++, un dynamique
(mais qui possède des aspects statiques), l'héritage,
et un statique, les templates.
Dans cette approche, SmallTalk est purement dynamique.

La doc d'Apple sur le langage Objective-C explique tres bien tout ca
dans sont 1er chapitre:

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf

En particulier les subtilites dans le polymorphisme dynamique et il est
facile de voir ce que C++ ne fait pas... Ceci dit cela peut etre
implemente a l'aide de classes.

a+, ld.

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

Jean-Marc Bourguet wrote:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

C'est à dire que pour toi, la généricité est dynamique et que tu
ne fait pas une distinction polymorphisme dynamique (héritage) et
polymorphisme statique (généricité) ?

L'aspect statique ou dynamique me semble complement independant. Je
peux concervoir un langage ou tout est dynamique ou tout statique
(mais bien plus contraint). En ce qui concerne le polymorphisme de
substitution -- l'heritage n'est qu'un moyen de l'obtenir -- la
version C++ me semble parmis les plus statiques possibles sans
contraintes redihibitives.

C'est à dire que tu ne vois pas la généricité C++ comme un moyen
de faire du polymorphisme de substitution.

Ce n'est qu'un aspect accessoire des templates en C++. Leur aspect
principal est la genericite.

La difference entre polymorphisme de substitution et polymorphisme
parametrique est que les operations sur les parametres sont
implicites dans le premier (elles sont deduites du type) et
explicite dans le second.

Je suis pas bien sur de comprendre ton argumentation. Pour moi,
l'héritage C++/Java/Eiffel fait un polymorphisme de substitution
dans lequel les parametres sont explicites,

Ils sont figes, pour un type donne (pour une combinaison de type dans
le cas du dispatch multiple).

Alors qu'avec un template, ce sera implicite.

Tu peux passer un parametre template pointeur vers membre.

template <typename T, int (T::*foo)(int) = &T::foo >
class C
{
public:
int applyFoo(T t, int i) { return (t.*foo)(i); }
};

class A
{
public:
int operator[](int);
};

C<A, &A::operator[]> c;

L'aspect polymorphisme de substitution n'est qu'un moyen d'avoir des
bons defauts mais passer a l'etape superieure est parfois interessant.
Naturellement si on fait ca pour beaucoup de membres, on va plutot
passer par une classe de traits.

Non ?

La situation en C++ est compliquee parce que les templates ont aussi
un aspect substitutionnel -- et un aspect ad hoc d'ailleurs -- qui
sert souvent: on ne passe pas souvent les operations possibles
explicitement (et les traits sont souvent utilises quand on le fait
pour retrouver de l'implicite).

Oui, pour moi, il y a deux polymorphismes en C++, un dynamique
(mais qui possède des aspects statiques), l'héritage,
et un statique, les templates.

Les templates c'est le moyen d'avoir la genericite en C++, mais c'est
plus que ca; de meme que les classes, c'est le moyen privilegie
d'avoir du polymorphisme de substitution mais c'est plus que ca (c'est
aussi, surtout, le moyen d'avoir de l'encapsulation).

Il y a les concepts et leur expression dans un langage donne. Il ne
faut pas se restraindre a une vision des concepts tels qu'ils sont
fournis par un langage -- ni considerer des concepts comme
inseparables parce qu'un langage unifie/confonds (qui donc disait
qu'il n'y avait qu'une difference de desirabilite entre ces deux
termes?) les deux.

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

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

| Jean-Marc Bourguet wrote:
| > Fabien LE LEZ <gramster@gramster.com> writes:
| >
| >> On 22 Jan 2004 02:02:44 -0800, kanze@gabi-soft.fr wrote:
| >>
| >> >Je dirais même que l'apport le plus important, ce n'est pas l'OO, mais
| >> >l'encapsulation -- la partie privée d'une classe et les fonctions
| >> >membres.
| >>
| >> Euh... Cela ne fait-il pas partie de l'OO ?
| >
| > Non. (De même la généricité n'en fait pas partie.)
|
| C'est à dire que pour toi, la généricité est dynamique
| et que tu ne fait pas une distinction polymorphisme
| dynamique (héritage) et polymorphisme statique (généricité) ?

Non.

-- Gaby

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

| > La difference entre polymorphisme de substitution et polymorphisme
| > parametrique est que les operations sur les parametres sont implicites
| > dans le premier (elles sont deduites du type) et explicite dans le
| > second.
|
| Je suis pas bien sur de comprendre ton argumentation.
| Pour moi, l'héritage C++/Java/Eiffel fait un polymorphisme
| de substitution dans lequel les parametres sont explicites,
| puisque donné par le typage que le programmeur doit expliciter.
|
| class X { void foo(); };
| class XX : public X {};
| class Y { void foo(); };
|
| Si j'écris une fonction qui a besoin que son argument
| possède une méthode foo, avec l'héritage, je dois donner
| un type (*X ou &X) et seules les classes descendant
| explicitement de X pourront être paramêtre.
| Alors qu'avec un template, ce sera implicite.
|
| Non ?

Non. Tu sembles confondre syntaxe et sémantique.

| > La situation en C++ est compliquee parce que les templates ont aussi
| > un aspect substitutionnel -- et un aspect ad hoc d'ailleurs -- qui
| > sert souvent: on ne passe pas souvent les operations possibles
| > explicitement (et les traits sont souvent utilises quand on le fait
| > pour retrouver de l'implicite).
|
| Oui, pour moi, il y a deux polymorphismes en C++, un dynamique
| (mais qui possède des aspects statiques), l'héritage,
| et un statique, les templates.

Et la surcharge, tu la ranges où ?

« On Data abstraction and Polymorphism in C++ », ACCU02
http://www.cmla.ens-cachan.fr/~dosreis/C++/talks/data-abstraction-and-polymorphism.pdf

-- Gaby

Gabriel Dos Reis on Tuesday 27 January 2004 09:16 :

Et la surcharge, tu la ranges où ?

Dans le coffre pardi !

Je m'excuse de faire irruption dans vos forums par cette boutade idiote
et hors-sujet de surcroit mais j'aurai certainement à vous poser des
questions par la suite.

Je lis ce qui est posté sur fco et ce fil est crossposté sur C++, j'en
profite pour poser 3 questions qui sembleront peut-être un peu "terre à
terre" :
1. Ce langage (C++) n'est-il pas parfois inutilement compliqué pour un
gain relativement faible, la complexité induisant des coûts dus à un
necessaire investissement des programmeurs dans la connaissance de ce
langage ?
2. Il se peut que je trouve compliqué ce qui ne l'est peut-être pas
tant, les bases de la syntaxe semblent assez évidentes pour une
personne qui connais C mais il me semble beaucoup plus facile d'aborder
la POO en passant par un langage comme Ruby par exemple.
3. Je sais plus ...

Je tiens à préciser que si je pense actuellement que l'approche objet
est la plus pertinente, il m'est aussi arrivé par le passé de penser
que d'autres approches (genre programmation structurée, modulaire,
machin etc.) étaient le top insurmontable, ainsi je pense maintenant
que nous devons garder un niveau d'abstraction au-dessus de l'approche
que nous choisissons.

Pour ce faire et pour essayer d'aller à contre-courant de "ce qui se
fait", j'instruis en ce moment un procès en réhabilitation du
"goto" (les plus anciens en ont sans doute déjà entendu parlé, ça ne se
trouve plus guère que dans le cobol et le kernel Linux). Cette
instruction injustement méprisée et jetée dans la gehenne mérite
beaucoup plus, je l'étudie en ce moment dans une optique focalisée sur
la théorie des graphes et les automates d'états.

Je recherche ici une hybridation avec l'approche objet qui ne soit pas
trop contre-nature.

--
Patrick
Pas serieux, s'abstenir.