Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ Vocabulaire.

Vocabulaire.

42 réponses
Avatar
Alexis Guillaume
Bonjour =E0 tous.

Je suis en train de concevoir une hi=E9rarchie de classe en C++ :

class base {
public:
virtual void foo();
};

Dans les commentaires, j'impose que si foo() est d=E9riv=E9e dans une
classe fille, alors cette m=E9thode d=E9riv=E9e doit aussi appeler
explicitement base::foo() apr=E8s avoir fait ce qu'elle voulait. Plus
g=E9n=E9ralement, si on a C qui h=E9rite de B et B qui h=E9rite base, et qu=
e B
et C d=E9rivent foo(), alors C::foo() doit appeler B::foo() et B::foo()
doit appeler base::foo().

Je dois r=E9diger un document de conception et j'ai bien du mal =E0
trouver comment appeler ce genre de fonctions virtuelles. Je pensais =E0
quelque chose comme "m=E9thode virtuelle cha=EEn=E9e"... Mais il y a
s=FBrement mieux et il y a peut-=EAtre m=EAme un mot qui existe d=E9j=E0 po=
ur
cela auquel cas c'est bien s=FBr lui que j'emploirai.

Merci pour vos avis =E9clair=E9s.
Alexis Guillaume.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
pjb
James Kanze writes:

On Mar 5, 12:13 pm, (Pascal J. Bourguignon)
wrote:
James Kanze writes:
> On Mar 4, 4:27 pm, (Pascal J. Bourguignon)
> wrote:
>> Alexis Guillaume writes:
>> >> Il y a le pattern "chaine de responsabilité" que tu peux
>> >> employer. Ca a l'air d'en être une forme (je ne peux pas
>> >> dire avec les éléments que tu donnes).



>> > En effet je me renseigne sur ce pattern et ça a l'air d'être
>> > ce que je veux faire. Merci beaucoup ! :-)



>> Oui, enfin, c'est le fonctionnement normal en programmation
>> objet quand on surcharge une méthode, d'appeler la méthode de
>> la superclass.



> Je dirais plutôt que c'est une symptome d'une mauvaise
> conception. En général, on ne supplante que des fonctions
> virtuelles pures.



Pas en POO. L'héritage est un élément essentiel de la POO.



Oui, mais l'héritage de quoi ? De l'interface, ou de
l'implémentation ? En C++, on fait la distinction.

OO = {héritage, encapsulation, polymorphisme, abstraction}.



Si on se contente de définir des interfaces d'un côté, et de
les implémenter d'un autre, on exclu l'héritage, et on ne
programme pas en OO.



Qu'est-ce que tu racontes là ? L'implémentation d'une
interface, c'est bien l'héritage.



Non. On peut définir des interfaces, et les implémenter dans des
langages qui ne sont pas orientés objets.



C'est vrai qu'il y a un certain temps, au début, quand il n'y
avait que du Smalltalk, la situation était différente. Mais
notre compréhension a évolué depuis. Ainsi que des démandes de
robustesse et de la vérification statique des types.




C++ n'est pas un progrès, c'est une régression. La référence en pur
OO (héritage simple) c'est Smalltalk, et CLOS pour la richesse du
système OO (incluant héritage multiple).




Ce qui est très beau, mais il ignore l'essentiel de l'idiome
consacré. Dans l'idiome consacré, attachWheel ne serait pas
virtuelle, mais appelerait une fonction privée (doAttachWheel)
qui elle serait virtuelle. Si on appelle attachWheel à travers
l'interface Automobile, on doit respecter le contrat de
Automobile::attachWheel ; il n'y a que si on l'appelle à
travers l'interface RusticAutomobile qu'on a droit d'attacher
une roue carrée.



Et donc tu ne peux pas substituer une RusticAutomobile avec roues
carrées à une Automobile, puisque Automobile::attachWheel refuse les
roues carrés. Donc tu ne peux pas étendre ton programme, donc tu ne
peux pas le réutiliser. Bravo.



Enfin, ceci dit, c'est une difficulté constante avec C++, et dans avec
les discussions que l'on peut avoir à propose de C++ : C++ n'est pas
un langage fini. Il faut que l'on specifie le type de système objet
que l'on veut, le type de gestion de mémoire que l'on veut, etc, et
qu'on implémente les bibliothèques et templates nécessaires pour
terminer le langage selon ces spécifications, et enfin que l'on
s'abstienne d'utiliser ce qui est imcompatible avec nos
spécifications, mais qui reste dans le langage.

Si je spécifie comme système OO un système similaire à Smalltalk, il
ne faudra bien sur jamais utiliser de fonctions membre non virtuelles.
Si je spécifie une gestion de la mémoire à base de smart pointers, il
ne faudra pas utiliser de pointeurs normaux.

Finalement chaque application et chaque bibliothèque écrits en C++
défini son propre dialect, et risque d'être incompatible avec les
autres. Ça n'aide pas à la réutilisation, mais pour ce qui nous
concerne, ça n'aide pas non plus à la discussion car manifestement
nous parlons de langages et de notions différentes.


Bref, C++, ce n'est pas un progrès.
--
__Pascal Bourguignon__
Avatar
Fabien LE LEZ
On Thu, 05 Mar 2009 15:10:08 +0100, (Pascal J.
Bourguignon):

Et donc tu ne peux pas substituer une RusticAutomobile avec roues
carrées à une Automobile, puisque Automobile::attachWheel refuse les
roues carrés.



Ce qui est une bonne chose : si on met comme condition que les roues
sont rondes, ce fait est probablement utilisé un peu partout dans le
code d'Automobile (ou de ses dérivées). Si tout à coup tu supprimes
cette condition, il faut bien revoir tout ton code -- ou créer une
nouvelle hiérarchie "voitures à roues carrées".
Avatar
Fabien LE LEZ
On Thu, 05 Mar 2009 15:10:08 +0100, (Pascal J.
Bourguignon):

Bref, C++, ce n'est pas un progrès.



Stroustrup est un vicieux : il a conçu C++ dans le but de faire hurler
les puristes.

(Quoique... les puristes doivent râler encore plus en voyant PHP,
langage mal conçu (voire pas conçu du tout), fait de bric et de broc,
mais qui a su s'imposer malgré l'absence de moyens marketing façon Sun
ou Microsoft...
PHP, le paratonnerre de C++ ! :-p )
Avatar
pjb
Fabien LE LEZ writes:

On Thu, 05 Mar 2009 15:10:08 +0100, (Pascal J.
Bourguignon):

Et donc tu ne peux pas substituer une RusticAutomobile avec roues
carrées à une Automobile, puisque Automobile::attachWheel refuse les
roues carrés.



Ce qui est une bonne chose : si on met comme condition que les roues
sont rondes, ce fait est probablement utilisé un peu partout dans le
code d'Automobile (ou de ses dérivées). Si tout à coup tu supprimes
cette condition, il faut bien revoir tout ton code -- ou créer une
nouvelle hiérarchie "voitures à roues carrées".




Tu n'as pas lu RusticAutomobile::attachWheel.

La précondition de Automobile::attachWheel est toujours assurée!

--
__Pascal Bourguignon__
Avatar
pjb
Fabien LE LEZ writes:

On Thu, 05 Mar 2009 15:10:08 +0100, (Pascal J.
Bourguignon):

Bref, C++, ce n'est pas un progrès.



Stroustrup est un vicieux : il a conçu C++ dans le but de faire hurler
les puristes.

(Quoique... les puristes doivent râler encore plus en voyant PHP,
langage mal conçu (voire pas conçu du tout), fait de bric et de broc,
mais qui a su s'imposer malgré l'absence de moyens marketing façon Sun
ou Microsoft...
PHP, le paratonnerre de C++ ! :-p )



Sans parler de perl! :-)

--
__Pascal Bourguignon__
Avatar
James Kanze
On Mar 5, 3:10 pm, (Pascal J. Bourguignon)
wrote:
James Kanze writes:
> On Mar 5, 12:13 pm, (Pascal J. Bourguignon)
> wrote:
>> James Kanze writes:
>> > On Mar 4, 4:27 pm, (Pascal J. Bourguignon)
>> > wrote:
>> >> Alexis Guillaume writes:
>> >> >> Il y a le pattern "chaine de responsabilité" que tu
>> >> >> peux employer. Ca a l'air d'en être une forme (je ne
>> >> >> peux pas dire avec les éléments que tu donnes).



>> >> > En effet je me renseigne sur ce pattern et ça a l'air
>> >> > d'être ce que je veux faire. Merci beaucoup ! :-)



>> >> Oui, enfin, c'est le fonctionnement normal en
>> >> programmation objet quand on surcharge une méthode,
>> >> d'appeler la méthode de la superclass.



>> > Je dirais plutôt que c'est une symptome d'une mauvaise
>> > conception. En général, on ne supplante que des fonctions
>> > virtuelles pures.



>> Pas en POO. L'héritage est un élément essentiel de la POO.



> Oui, mais l'héritage de quoi ? De l'interface, ou de
> l'implémentation ? En C++, on fait la distinction.



>> OO = {héritage, encapsulation, polymorphisme, abstraction}.



>> Si on se contente de définir des interfaces d'un côté, et
>> de les implémenter d'un autre, on exclu l'héritage, et on
>> ne programme pas en OO.



> Qu'est-ce que tu racontes là ? L'implémentation d'une
> interface, c'est bien l'héritage.



Non. On peut définir des interfaces, et les implémenter dans
des langages qui ne sont pas orientés objets.



Pas de la même façon. (C'est sûr que le concepte d'interface
dépasse largement les bornes de OO. Quelque soit ces bornes
exactement.)

> C'est vrai qu'il y a un certain temps, au début, quand il
> n'y avait que du Smalltalk, la situation était différente.
> Mais notre compréhension a évolué depuis. Ainsi que des
> démandes de robustesse et de la vérification statique des
> types.



C++ n'est pas un progrès, c'est une régression. La référence
en pur OO (héritage simple) c'est Smalltalk, et CLOS pour la
richesse du système OO (incluant héritage multiple).



Le concepte d'OO a bien ses origines dans Smalltalk. Depuis, on
a évolué, voir Eiffel, par exemple (qui lui aussi commence à
montrer son âge). (Et évidemment, ce que c'est exactement le OO
dépend bien à qui on démande. Alan Kay en donnerait bien une
autre définition que Bertrand Meyer.)

Enfin, je suis moins intéressé par le nom qu'on donne (ou non)
au concepte. Ce qui m'intéresse, c'est de pouvoir écrire du code
robuste et facilement maintenable. Dans l'ensemble, mes idées
sur le OO coïncide assez avec ce de Bertrand Meyer ; c-à-d que
j'y integre la programmation par contrat.

> Ce qui est très beau, mais il ignore l'essentiel de l'idiome
> consacré. Dans l'idiome consacré, attachWheel ne serait pas
> virtuelle, mais appelerait une fonction privée
> (doAttachWheel) qui elle serait virtuelle. Si on appelle
> attachWheel à travers l'interface Automobile, on doit
> respecter le contrat de Automobile::attachWheel ; il n'y a
> que si on l'appelle à travers l'interface RusticAutomobile
> qu'on a droit d'attacher une roue carrée.



Et donc tu ne peux pas substituer une RusticAutomobile avec
roues carrées à une Automobile, puisque
Automobile::attachWheel refuse les roues carrés. Donc tu ne
peux pas étendre ton programme, donc tu ne peux pas le
réutiliser. Bravo.



Apparamment, tu n'as pas régardé le code que j'ai fourni.
RusticAutomobile dérive publiquement d'Automobile, et peut
servir partout où Automobile peut servir. Elle implémente
l'interface Automobile (avec le contrat d'Automobile dans cette
interface).

Enfin, ceci dit, c'est une difficulté constante avec C++, et
dans avec les discussions que l'on peut avoir à propose de
C++ : C++ n'est pas un langage fini.



C'est exactement son avantage. Il n'y a pas de concepte
particulier de OO integré dans le langage ; le langage contient
des structures qui te permettent à implémenter le modèle de OO
qui te convient le mieux. Modèle qui, évidemment, évolue avec le
temps, au fur et à mesure que notre compréhension du concepte
augmente. D'après le peu que j'en connais, CLOS en fait autant,
à partir des bases bien différentes, évidemment. La plupart des
autres langages « OO », en revanche, adopte l'interprêtation
de OO qui était courante lors de leur conception, et se revèle
rapidement démodés.

Il faut que l'on specifie le type de système objet que l'on
veut, le type de gestion de mémoire que l'on veut, etc, et
qu'on implémente les bibliothèques et templates nécessaires
pour terminer le langage selon ces spécifications, et enfin
que l'on s'abstienne d'utiliser ce qui est imcompatible avec
nos spécifications, mais qui reste dans le langage.



Comme l'Eiffel, le C++ utilise un typage statique, oui. C'est un
apporte signifiante à la robustesse et la fiabilité du code,
c'est sûr. Ça a un prix au niveau de la souplesse, mais pas
autant que tu sembles croire -- même dans un langage typé
dynamiquement, comme Smalltalk ou Lisp, on ne peut pas faire
n'importe quoi dans une sous-classe et s'attendre à ce que ça
marche.

Si je spécifie comme système OO un système similaire à
Smalltalk,



Tu te limites à une catégorie des systèmes OO. Catègorie qui est
bien adoptée à la programmation dymamique, expérimentale, mais
qui rend l'écriture des systèmes robuste et qui peuvent être
maintenu par quelqu'un d'autre que l'auteur plus difficile.

il ne faudra bien sur jamais utiliser de fonctions membre non
virtuelles.



Or que si on veut du code ultra-robuste, et facilement
maintenable, il vaut mieux que des fonctions publiques
virtuelles soient assez rares -- en dehors des inversions de
l'appel, je n'en vois pas.

Si je spécifie une gestion de la mémoire à base de smart
pointers, il ne faudra pas utiliser de pointeurs normaux.



Là, tu touches à un autre aspect, où effectivement, C++
(standard) a une faiblesse. Ou plutôt deux problèmes, liés mais
quand même distincts. Le premier, évidemment, c'est l'absence
d'un glaneur de cellules standard ; on peut utiliser celui de
Boehm (ce que je fais parfois), mais l'utilisation n'en est pas
très répandue, et si tu écris par exemple une bibliothèque, tu
ne peux pas compté sur sa présence. L'autre, c'est cette manie
d'utiliser les pointeurs intelligents partout. Ils sont bien
utiles dans certains cas précis, mais en général, on ne doit pas
alloué des types à sémantique de valeur dynamiquement (ce qui
veut dire que des types à sémantique de valeur ne sont jamais
polymorphique), et les types dit d'« entité » (« entity
types », en anglais -- je ne sais pas s'il y en a une
traduction consacrée en français) ont une durée de vie explicite
que soit ils gèrent eux-même, soit qui est gérée par un
composant dédié (gestionnaire de transaction, etc.). Du coup, la
vaste majorité de pointeurs sont uniquement pour la navigation,
et le pointeur de base C++ y fait très bien l'affaire.

Finalement chaque application et chaque bibliothèque écrits en
C++ défini son propre dialect, et risque d'être incompatible
avec les autres. Ça n'aide pas à la réutilisation, mais pour
ce qui nous concerne, ça n'aide pas non plus à la discussion
car manifestement nous parlons de langages et de notions
différentes.



Bref, C++, ce n'est pas un progrès.



Non, mais il permet du progrès. Ce qui n'est pas le cas des
langages qui impose une version précise d'un seul concepte comme
unique modèle de programmation.

--
James Kanze (GABI Software) email:
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
Avatar
Wykaaa
James Kanze a écrit :
On Mar 5, 3:10 pm, (Pascal J. Bourguignon)
wrote:
James Kanze writes:
On Mar 5, 12:13 pm, (Pascal J. Bourguignon)
wrote:
James Kanze writes:
On Mar 4, 4:27 pm, (Pascal J. Bourguignon)
wrote:
Alexis Guillaume writes:
Il y a le pattern "chaine de responsabilité" que tu
peux employer. Ca a l'air d'en être une forme (je ne
peux pas dire avec les éléments que tu donnes).















En effet je me renseigne sur ce pattern et ça a l'air
d'être ce que je veux faire. Merci beaucoup ! :-)













Oui, enfin, c'est le fonctionnement normal en
programmation objet quand on surcharge une méthode,
d'appeler la méthode de la superclass.











Je dirais plutôt que c'est une symptome d'une mauvaise
conception. En général, on ne supplante que des fonctions
virtuelles pures.









Pas en POO. L'héritage est un élément essentiel de la POO.







Oui, mais l'héritage de quoi ? De l'interface, ou de
l'implémentation ? En C++, on fait la distinction.





OO = {héritage, encapsulation, polymorphisme, abstraction}.







Si on se contente de définir des interfaces d'un côté, et
de les implémenter d'un autre, on exclu l'héritage, et on
ne programme pas en OO.







Qu'est-ce que tu racontes là ? L'implémentation d'une
interface, c'est bien l'héritage.





Non. On peut définir des interfaces, et les implémenter dans
des langages qui ne sont pas orientés objets.



Pas de la même façon. (C'est sûr que le concepte d'interface
dépasse largement les bornes de OO. Quelque soit ces bornes
exactement.)

C'est vrai qu'il y a un certain temps, au début, quand il
n'y avait que du Smalltalk, la situation était différente.
Mais notre compréhension a évolué depuis. Ainsi que des
démandes de robustesse et de la vérification statique des
types.





C++ n'est pas un progrès, c'est une régression. La référence
en pur OO (héritage simple) c'est Smalltalk, et CLOS pour la
richesse du système OO (incluant héritage multiple).



Le concepte d'OO a bien ses origines dans Smalltalk. Depuis, on
a évolué, voir Eiffel, par exemple (qui lui aussi commence à
montrer son âge). (Et évidemment, ce que c'est exactement le OO
dépend bien à qui on démande. Alan Kay en donnerait bien une
autre définition que Bertrand Meyer.)



La programmation objet n'a pas ses origines dans Smalltalk mais dans
SIMULA, et ce, dès 1962 !
Voir, par exemple :
http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

Enfin, je suis moins intéressé par le nom qu'on donne (ou non)
au concepte. Ce qui m'intéresse, c'est de pouvoir écrire du code
robuste et facilement maintenable. Dans l'ensemble, mes idées
sur le OO coïncide assez avec ce de Bertrand Meyer ; c-à-d que
j'y integre la programmation par contrat.



Très bonne remarque. Ce qu'a écrit Bertrand Meyer sur l'objet est ce
qu'il y a de mieux, à mon avis.

[couic le reste]
Avatar
pjb
Wykaaa writes:

Le concepte d'OO a bien ses origines dans Smalltalk. Depuis, on
a évolué, voir Eiffel, par exemple (qui lui aussi commence à
montrer son âge). (Et évidemment, ce que c'est exactement le OO
dépend bien à qui on démande. Alan Kay en donnerait bien une
autre définition que Bertrand Meyer.)



La programmation objet n'a pas ses origines dans Smalltalk mais dans
SIMULA, et ce, dès 1962 !
Voir, par exemple :
http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

Enfin, je suis moins intéressé par le nom qu'on donne (ou non)
au concepte. Ce qui m'intéresse, c'est de pouvoir écrire du code
robuste et facilement maintenable. Dans l'ensemble, mes idées
sur le OO coïncide assez avec ce de Bertrand Meyer ; c-à-d que
j'y integre la programmation par contrat.



Très bonne remarque. Ce qu'a écrit Bertrand Meyer sur l'objet est ce
qu'il y a de mieux, à mon avis.



Nous sommes d'accord.

--
__Pascal Bourguignon__
Avatar
James Kanze
On Mar 6, 2:33 pm, Wykaaa wrote:
James Kanze a écrit :



[...]
> Le concepte d'OO a bien ses origines dans Smalltalk. Depuis,
> on a évolué, voir Eiffel, par exemple (qui lui aussi
> commence à montrer son âge). (Et évidemment, ce que c'est
> exactement le OO dépend bien à qui on démande. Alan Kay en
> donnerait bien une autre définition que Bertrand Meyer.)



La programmation objet n'a pas ses origines dans Smalltalk
mais dans SIMULA, et ce, dès 1962 ! Voir, par exemple
:http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html



Mais est-ce qu'ils l'ont appelé OO ? J'avais bien connaissance
de SIMULA, et sa rôle, mais j'ai toujours cru que c'était Alan
Kay qui a créé l'expression « object oriented » pour Smalltalk.

Il me semble que Simula utilisait le typage statique, comme C++,
Eiffel, Java..., et non le typage dynamique de Smalltalk. Et
qu'il y a bien quelques inconditionnels de Smalltalk qui insiste
que sans typage dynamique, ce n'est pas du OO.

--
James Kanze (GABI Software) email:
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
Avatar
Jean-Marc Bourguet
James Kanze writes:

Mais est-ce qu'ils l'ont appelé OO ? J'avais bien connaissance
de SIMULA, et sa rôle, mais j'ai toujours cru que c'était Alan
Kay qui a créé l'expression « object oriented » pour Smalltalk.



Non, c'est bien Alan Kay l'inventeur du terme. Pour décrire une technique
qu'il avait vue dans un OS, dans Simula et dans un éditeur graphique. Il a
érigé cette technique en principe de conception et inventé un langage
adapté à son utilisation. (De mémoire d'après le papier d'Alan Kay dans
HOPL II)

Il me semble que Simula utilisait le typage statique, comme C++,
Eiffel, Java..., et non le typage dynamique de Smalltalk.



Exact.

--
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
1 2 3 4 5