C++0x et multi-method

On 31 mai, 01:39, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

La question n'est pas si c'est possible -- tout le monde sait que c'est
possible, de la même manière que c'est possible de faire de la
programmation orientée objet en C.  La vraie question est à quel co ût,
et comment les « trics » mis en oeuvre soutiennent une programmation
propre, efficace, donnant lieu à des programmes maintenables.  C'est
pour cela que je recommende vivement de lire le papier en question (pas
juste parcourir) pour avoir une bonne idée de la problèmatique.
Autrement, on peut pas avancer.

Ok, j'ai bien pris le temps de lire le papier de B.S. Commentaires sur
le papier plus bas dans ce message.

| Bref, je ne penses pas que ce soit le genre de choses qui mériteraien t
| que l'on passe encore un moment à l'intégrer à la norme.

Pourquoi ? Quels sont tes arguments ?

Je me suis mal exprimé. Je disais qu'il me semble que l'on est trop
tard dans le processus de normalisation de C++0x pour l'intégrer.

Laurent avait indiqué, je cite :

  # Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
  # methods" proposees par B.S. et al. (a GPCE'07)
                                          ^^^^^^^

     http://www.research.att.com/~bs/multimethods.pdf

Au temps pour moi.

Mon avis sur la proposition : très intéressante, utile, avec deux
aspects négatifs évidents :
- encore un nouveau mot-clé qui va avoir des utilisations différentes.
'const', 'typename' en sont des examples. 'virtual' est déjà utilisé
au niveau des fonctions membres et de l'héritage. Cela ne va pas
faciliter la tâche pour les débutants.
- il y a quand même du boulot derrière (bien que mâché par B.S. gr âce
à ce papier) pour ceux qui écrivent les compilos C++, ce qui signifie
qu'il faudra encore attendre un moment après le jour où l'on aura
décidé de rajouter cela à C++.

mais des aspects positifs tout aussi évidents :
- C'est assez simple, finalement. Quelqu'un ayant un minimum de
connaissance et d'expérience en C++ n'aura pas de mal à utiliser cette
"extension".
- Le multiple dispatch est quelque chose que l'on rencontre finalement
assez souvent. Avoir une solution directement offerte par le langage,
ce serait excellent.

Un C++ avec le support de ce qui est proposé par BS serait
probablement plus pratique qu'une bibliothèque, comme dans Loki où
l'on doit "choisir" parmi des solutions offrant diverses possibilités
en termes de performance, maintenabilité et "intrusion" (?).
Toutefois, ce que je disais me paraît moins intelligent après
réflexion. C'est comme si l'on préférait les concept checking tels
qu'implémentés dans Boost plutôt que les concepts directement intég rés
dans C++0x. Il n'en demeure pas moins que l'on aura pas cela pour C+
+0x, vu les changements à envisager et le temps nécessaire, non ?

On 31 mai, 04:03, Alp Mestan <alpmes...@gmail.com> wrote:

On 31 mai, 01:39, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

> La question n'est pas si c'est possible -- tout le monde sait que c'est
> possible, de la même manière que c'est possible de faire de la
> programmation orientée objet en C.  La vraie question est à quel coût,
> et comment les « trics » mis en oeuvre soutiennent une programmatio n
> propre, efficace, donnant lieu à des programmes maintenables.

Exactement. Car il y a 4 differences fondamentales entre ce qui est
actuellement possible et les multi-methods:

- le couplage statique tres problematique dans le Visitor Pattern (ou
une map avec registration)
- l'extensibility (open method)
- single-dispatch sequence vs multi-dispatch qui n'ont pas la meme
semantique
- l'efficacite et la gestion de l'heritage

Si on y regarde de pres, les multi-methods sont l'equivalent dynamique
des templates. Alors que C++ est deja tres bien equipe pour la
programmation statique (et plus avec les concepts), il est
particulierement rigide dans le domaine dynamique d'ou l'importance
d'avoir les multimethodes aujourd'hui (et pas dans 10 ans).

>  C'est
> pour cela que je recommende vivement de lire le papier en question (pas
> juste parcourir) pour avoir une bonne idée de la problèmatique.
> Autrement, on peut pas avancer.

Ok, j'ai bien pris le temps de lire le papier de B.S. Commentaires sur
le papier plus bas dans ce message.

> | Bref, je ne penses pas que ce soit le genre de choses qui mériterai ent
> | que l'on passe encore un moment à l'intégrer à la norme.

> Pourquoi ? Quels sont tes arguments ?

Je me suis mal exprimé. Je disais qu'il me semble que l'on est trop
tard dans le processus de normalisation de C++0x pour l'intégrer.

Ca c'est probable et c'est bien dommage car l'impact sur la facon
d'utiliser C++ aurait ete bien au-dela que toutes les autres futures
additions reunies a mon avis.

> Laurent avait indiqué, je cite :

>   # Est-ce que quelqu'un sait s'il y a une chance que les "open multi -
>   # methods" proposees par B.S. et al. (a GPCE'07)
>                                           ^^^^^^^

>      http://www.research.att.com/~bs/multimethods.pdf

Au temps pour moi.

;-)

Mon avis sur la proposition : très intéressante, utile, avec deux
aspects négatifs évidents :
- encore un nouveau mot-clé

il n'est pas nouveau

qui va avoir des utilisations différentes.

et son utilisation n'est pas differente

'const', 'typename' en sont des examples. 'virtual' est déjà utilis é
au niveau des fonctions membres et de l'héritage. Cela ne va pas
faciliter la tâche pour les débutants.

Poutant il a la meme semantique dans les deux cas... il suffit de
compendre que

class A {
virtual void foo();
}

est equivalent a

void foo(virtual A* this);

hormis biensur les portees (je parle seulement de virtual ici)

- il y a quand même du boulot derrière (bien que mâché par B.S. g râce
à ce papier) pour ceux qui écrivent les compilos C++, ce qui signifie
qu'il faudra encore attendre un moment après le jour où l'on aura
décidé de rajouter cela à C++.

Ca c'est un probleme de communication. Rien n'empeche de faire un
papier qui detail l'ABI et le modele objet pour expliquer comment
l'implementer. Le compilateur a deja tous les outils en mains puisque
les templates et les vtbl sont deja la. Il s'agit "seulement"
d'unifier et de generaliser l'existant. Mais c'est un gros boulot, je
te l'accorde.

mais des aspects positifs tout aussi évidents :
- C'est assez simple, finalement. Quelqu'un ayant un minimum de
connaissance et d'expérience en C++ n'aura pas de mal à utiliser cett e
"extension".

pas si simple en fait, car cela vient se superposer a l'ADL qui n'est
deja pas tres simple.

- Le multiple dispatch est quelque chose que l'on rencontre finalement
assez souvent. Avoir une solution directement offerte par le langage,
ce serait excellent.

En fait, quand on l'a on ne s'en passe plus. La quasi totalite de mes
methodes en COS (C Object System) sont des multimethodes, d'ou ma
question...

Un C++ avec le support de ce qui est proposé par BS serait
probablement plus pratique qu'une bibliothèque

Pas seulement. En C++, *il n'est pas possible* de l'implementer comme
une bibliotheque sans modifier le modele objet. Ce qui existe
aujourd'hui n'a pas la meme semantique, loin de la (y compris Loki).

comme dans Loki où
l'on doit "choisir" parmi des solutions offrant diverses possibilités
en termes de performance, maintenabilité et "intrusion" (?).
Toutefois, ce que je disais me paraît moins intelligent après
réflexion. C'est comme si l'on préférait les concept checking tels
qu'implémentés dans Boost plutôt que les concepts directement int égrés
dans C++0x. Il n'en demeure pas moins que l'on aura pas cela pour C+
+0x, vu les changements à envisager et le temps nécessaire, non ?

c'est ce que je pense malheureusement.

a+, ld.

On 30 mai, 06:28, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

ld <Laurent.Den...@gmail.com> writes:

| Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
| methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
| dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
| cela demande un changement significatif du modele objet (frein a son
| adoption?). Pourtant ca changerait enormement les possibilites
| "dynamiques" de C++.

Salut Gaby,

Je serai surpris si elles passent dans C++0x.

dommage.

J'en profite pour expliquer (pas particulierement a toi ;-) un peu
plus en details pourquoi c'est aussi important d'un point de vu design
de software (mon lobbing). Je pense qu'une des erreurs de design de C+
+, c'est d'avoir mis les methodes virtual comme membre des classes.
Elles auraient du en rester a l'exterieur. Cela aurait permis:

- de garantir le Liskov Subtitution Principle au lieu de le violer
systematiquement. On sait aujourd'hui qu'il est pratiquement
impossible de le satisfaire en presence du runtime polymorphism. Cela
aurait aussi grandement simplifie la notion de classe et leur design.
Le runtime polymorphism venant apres, comme une extension de
l'interface selon les besoins.

- d'etendre la partie collaborative des classes tout en conservant le
RAII. Un reel probleme en C++ pour satisfaire le "Separation of
Concern" c'est comment decomposer le code de maniere flexible. Les
Mixins sont trop statique (en C++) et antagoniste au RAII et les
alternatives (design patterns) tres peu flexible et compliquees a
maintenir.

- de generaliser l'overloading des fonctions, les "methodes" non
membre dont la flexibilite est souvent sous exploitee, au profit de
classes plus simple et mieux fermees avec des interfaces ouverte (a-la-
C) , mais aussi polymorphique et extensible.

De plus la generalisation de l'utilisation du CRTP et de l'heritage
parametrise permettent de subvenir a presque tous les besoins du
polymorphism d'heritage (statique), surtout avec les futurs variadic
templates et les concepts.

Ces trois points sont en fait une seul et meme chose, vu sous
differents angles. Bref avec les multi-methodes, la collaboration des
deux mondes (statique et dynamique) s'en seraient renforcee et le
design simplifie. Mais l'histoire s'est ecrite autrement...

Voila qques reflexion perso ;-)

a+, ld.

PS. l'etape d'apres c'est la delegation, mais c'est pas gagne avec C+
+ ;-)

On 31 mai, 01:39, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

Mathias Gaunard <loufo...@gmail.com> writes:

[...]

| > ca
| > ne peut donc pas marcher. Il faudrait plutot quelque chose base sur
| > boost any qui lui est dynamique. Mais les tentatives sont tres
| > lourdes, tres lentes et pas vraiment convainquantes.
|
| boost.variant fournit du multi-dispatch qui fonctionne à merveille (c e
| qui est l'objectif des multi-méthodes).
| Donc ça marche.

Fascinant.

;-)

Le chemin est long avant de voir les etoiles derriere la lune ;-)

a+, ld.

Bonjour Laurent,

On 31 mai, 10:40, ld <Laurent.Den...@gmail.com> wrote:

Si on y regarde de pres, les multi-methods sont l'equivalent dynamique
des templates.

C'est tout à fait comme ça que je l'ai perçu.

Alors que C++ est deja tres bien equipe pour la
programmation statique (et plus avec les concepts), il est
particulierement rigide dans le domaine dynamique d'ou l'importance
d'avoir les multimethodes aujourd'hui (et pas dans 10 ans).

Je me dis que quelque part, si on ne les aura pas pour C++0x mais
seulement après, c'est entre autre parce que personne n'a eu le temps
de faire avancer la proposition, et notamment elle est arrivée un peu
tard (2007). BS aura présenté cela en 2003 ou 2004 que ça aurait peut -
être fait son chemin.

> Mon avis sur la proposition : très intéressante, utile, avec deux
> aspects négatifs évidents :
> - encore un nouveau mot-clé

il n'est pas nouveau

Non, mais cette utilisation oui. Même si c'est assez proche de
l'utilisation pour les fonctions membres virtuelles et c'est
strictement la même chose après tout.

Ca c'est un probleme de communication. Rien n'empeche de faire un
papier qui detail l'ABI et le modele objet pour expliquer comment
l'implementer. Le compilateur a deja tous les outils en mains puisque
les templates et les vtbl sont deja la. Il s'agit "seulement"
d'unifier et de generaliser l'existant. Mais c'est un gros boulot, je
te l'accorde.

Mais ce serait effectivement excellent. On ne serait plus limité à la
virtualité par rapport à une classe. Après, on voit le bon côté, mais
il y aurait bien des problèmes qui feraient faire n'importe quoi au
débutant qui ne saisiraient pas bien comment ça marche, mais ça à l a
limite... On ne peut pas y faire grand chose à part expliquer.

Pas seulement. En C++, *il n'est pas possible* de l'implementer comme
une bibliotheque sans modifier le modele objet. Ce qui existe
aujourd'hui n'a pas la meme semantique, loin de la (y compris Loki).

Oui. Les solutions qui existent sont +- intrusives, +- souples, +-
maintenables. Celle-là serait bien sur tous ces aspects. Bref, si un
jour il est question de remettre cette proposition sur le tapis ce
serait plaisant.

ld a écrit :

Le chemin est long avant de voir les etoiles derriere la lune ;-)

Hmm... une heure d'attente sur une chaise longue doit suffire.

--
Richard

On 31 mai, 01:39, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

Mathias Gaunard <loufo...@gmail.com> writes:

[...]

| > ca
| > ne peut donc pas marcher. Il faudrait plutot quelque chose base sur
| > boost any qui lui est dynamique. Mais les tentatives sont tres
| > lourdes, tres lentes et pas vraiment convainquantes.
|
| boost.variant fournit du multi-dispatch qui fonctionne à merveille (c e
| qui est l'objectif des multi-méthodes).
| Donc ça marche.

Fascinant.

   http://www.research.att.com/~bs/multimethods.pdf

Je ne comprends pas trop pourquoi vous me donnez ce lien, que j'ai
d'ailleurs déjà lu il y a longtemps.
Je n'ai jamais dit que c'était équivalent.

Boost.Variant a bien entendu des restrictions, puisque ça ne
fonctionne qu'avec un nombre fini de types, et que c'est un modèle
différent de programmation que celui orienté objet.

Mais ça fait bel et bien du multiple-dispatch...
Multiple-dispatch qui est l'objectif des multi-méthodes au sein du
modèle de programmation orienté objet.

Je ne fais que proposer des solutions alternatives pour faire du
multiple-dispatch en C++, je n'ai jamais prétendu que c'était
équivalent aux multi-méthodes.
Se restreindre à un ensemble fini de types n'est souvent pas un
problème majeur pour les architectures objet, et face à l'absence de
multi-méthodes il faut bien faire des concessions.

La proposition parle d'ailleurs d'un outil de Loki pour faire du
multiple-dispatch qui nécessite de lister l'ensemble des classes dans
une type list, donc ce n'est pas une restriction si gênante.
Après la solution de Loki est lente car linéaire, mais elle fonctionne
avec le typage objet et ne nécessite pas l'information de typage
inhérente à un variant.
On pourrait néanmoins faire une solution à la Loki en temps constant
en utilisant des astuces, en utilisant le nom du type manglé et en le
comparant à std::type_info::name. J'ai d'ailleurs un projet de
bibliothèque dans Boost qui fait ça.

À part ça selon moi l'orienté objet est un paradigme assez mauvais,
donc je trouve le genre de solution que je propose (variant) plus
élégant, mais ce n'est que mon opinion personnelle.

Par ailleurs, permettre les fonctions templates virtuelles rendrait
possible un variant avec un ensemble de types non borné, ce qui
permettrait plein de choses utiles, comme des choses similaires à du
multi-dispatch ouvert (on peut simplement appliquer les règles de la
surcharge dynamiquement en passant un foncteur surchargé à une
fonction virtuelle template), et on pourrait même faire du duck typing
dynamique généralisé à tout type C++.
Ce serait un bien moins grand changement dans le langage que les multi-
méthodes, serait plus efficace, et pas plus dur à implémenter
qu'export.

Tiens d'ailleurs, ils en parlent même à la fin de la proposition, je
n'avais jamais remarqué.

On 31 mai, 12:12, ld <Laurent.Den...@gmail.com> wrote:

- de garantir le Liskov Subtitution Principle au lieu de le violer
systematiquement. On sait aujourd'hui qu'il est pratiquement
impossible de le satisfaire en presence du runtime polymorphism. Cela
aurait aussi grandement simplifie la notion de classe et leur design.
Le runtime polymorphism venant apres, comme une extension de
l'interface selon les besoins.

Il est trivial de le satisfaire dans tous les cas : faire des objets
immuables, ou alors utiliser une fonctionnalité fictive du genre class
B : const A

- d'etendre la partie collaborative des classes tout en conservant le
RAII. Un reel probleme en C++ pour satisfaire le "Separation of
Concern" c'est comment decomposer le code de maniere flexible. Les
Mixins sont trop statique (en C++) et antagoniste au RAII et les
alternatives (design patterns) tres peu flexible et compliquees a
maintenir.

Si tu fais de l'OO, de toutes façons, tu veux sûrement virer
constructeur de copie et opérateur d'affectation.
Désactiver ça prend deux lignes voire une, et le reste correspond bien
au code métier de l'objet, pas besoin de séparation.

- de generaliser l'overloading des fonctions, les "methodes" non
membre dont la flexibilite est souvent sous exploitee, au profit de
classes plus simple et mieux fermees avec des interfaces ouverte (a-la-
C) , mais aussi polymorphique et extensible.

Généraliser la fonctionnalité des multi-méthodes aux fonctions libr es
serait en effet une très bonne idée.
Au final struct A { virtual void foo(); }; serait vraiment struct A
{ void foo() virtual; };



Une solution très simple pour éviter tous les problèmes du
polymorphisme d'inclusion dynamique consiste à ne pas utiliser
d'héritage et de fonctions virtuelles, mais d'utiliser à la place les
templates et de simples fonctions, et de faire de la type erasure pour
les cas qui ont vraiment besoin d'être dynamiques.

Apparemment c'est plus cette approche de programmation qui plaît aux
gens qui travaillent sur le standard, et l'orienté objet est donc un
peu délaissé.

Bien sûr la type erasure on a toujours la même limitation qu'avec
l'objet : le type est perdu une fois qu'il a été effacé, et donc les
appels suivants ne vont pas le refiner. Mais si ceci est un problème,
c'est probablement que l'algorithme générique en question ne demande
pas les bons concepts à ses arguments.

Mathias Gaunard <loufoque@gmail.com> writes:

| On 31 mai, 01:39, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| > Mathias Gaunard <loufo...@gmail.com> writes:
| >
| > [...]
| >
| > | > ca
| > | > ne peut donc pas marcher. Il faudrait plutot quelque chose base sur
| > | > boost any qui lui est dynamique. Mais les tentatives sont tres
| > | > lourdes, tres lentes et pas vraiment convainquantes.
| > |
| > | boost.variant fournit du multi-dispatch qui fonctionne à merveil le (ce
| > | qui est l'objectif des multi-méthodes).
| > | Donc ça marche.
| >
| > Fascinant.
| >
| >    http://www.research.att.com/~bs/multimethods.pdf
|
| Je ne comprends pas trop pourquoi vous me donnez ce lien, que j'ai
| d'ailleurs déjà lu il y a longtemps.

C'est ce qui rend ta conclusion fascinante.

| Je n'ai jamais dit que c'était équivalent.

Il y a une section appelée « related work » -- qui en plus d u corps de
l'article -- discute brievement alternatives ainsi que quelques unes de
limitations. La section « results » montre a une comparaison ent re les
différents systèmes mentionnés où Loki occupe une place mémorable.

[...]

| La proposition parle d'ailleurs d'un outil de Loki pour faire du
| multiple-dispatch qui nécessite de lister l'ensemble des classes dans
| une type list, donc ce n'est pas une restriction si gênante.

comme la performance (taille du code, temps d'exécution) ?

| Après la solution de Loki est lente car linéaire, mais elle fon ctionne
| avec le typage objet et ne nécessite pas l'information de typage
| inhérente à un variant.
| On pourrait néanmoins faire une solution à la Loki en temps con stant
| en utilisant des astuces, en utilisant le nom du type manglé et en le
| comparant à std::type_info::name. J'ai d'ailleurs un projet de
| bibliothèque dans Boost qui fait ça.

Je me permets de me répéter ici :

# La question n'est pas si c'est possible -- tout le monde sait que c'est
# possible, de la même manière que c'est possible de faire de la
# programmation orientée objet en C. La vraie question est à q uel coût,
# et comment les « trics » mis en oeuvre soutiennent une progra mmation
# propre, efficace, donnant lieu à des programmes maintenables.

| À part ça selon moi l'orienté objet est un paradigme assez mauvais,

est-ce un postulat ?

| donc je trouve le genre de solution que je propose (variant) plus
| élégant, mais ce n'est que mon opinion personnelle.

[...]

| Tiens d'ailleurs, ils en parlent même à la fin de la propositio n, je
| n'avais jamais remarqué.

Interessant.

-- Gaby

Alp Mestan <alpmestan@gmail.com> writes:

[...]

| Mon avis sur la proposition : très intéressante, utile, avec de ux
| aspects négatifs évidents :
| - encore un nouveau mot-clé qui va avoir des utilisations diffé rentes.
| 'const', 'typename' en sont des examples. 'virtual' est déjà ut ilisé
| au niveau des fonctions membres et de l'héritage. Cela ne va pas
| faciliter la tâche pour les débutants.

Wow. Pour une fois qu'un mot clé est re-utilisé proprement dans le
contexte où il implique exactement la même notion qu'avant : la
sélection de la fonction est dynamique et function de l'argument en
position mentionnée.

| - il y a quand même du boulot derrière (bien que mâchà © par B.S. grâce
| à ce papier) pour ceux qui écrivent les compilos C++, ce qui si gnifie
| qu'il faudra encore attendre un moment après le jour où l'on au ra
| décidé de rajouter cela à C++.

Les étudiants n'ont pas mis beaucoup de temps une fois qu'on a expliqu é
les idées principales. Cela ne veut pas dire que ce n'est pas du boulo t,
mais je ne comprends pas pourquoi c'est un aspect négatif évident.
As-tu une liste de nouvelles fonctionnalités qui n'ont pas cet aspect
négatif évident ?

| mais des aspects positifs tout aussi évidents :
| - C'est assez simple, finalement. Quelqu'un ayant un minimum de
| connaissance et d'expérience en C++ n'aura pas de mal à utilise r cette
| "extension".

C'est le but cherché.

| - Le multiple dispatch est quelque chose que l'on rencontre finalement
| assez souvent. Avoir une solution directement offerte par le langage,
| ce serait excellent.
|
| Un C++ avec le support de ce qui est proposé par BS serait
| probablement plus pratique qu'une bibliothèque, comme dans Loki oà ¹
| l'on doit "choisir" parmi des solutions offrant diverses possibilités
| en termes de performance, maintenabilité et "intrusion" (?).
| Toutefois, ce que je disais me paraît moins intelligent après
| réflexion. C'est comme si l'on préférait les concept check ing tels
| qu'implémentés dans Boost plutôt que les concepts directem ent intégrés
| dans C++0x.

Je ne suis pas en désaccord.

| Il n'en demeure pas moins que l'on aura pas cela pour C+
| +0x, vu les changements à envisager et le temps nécessaire, non ?

Oui, mais cela ne diminue pas la valeur de la proposition elle-même.
Il y a beaucoup de bonnes choses qu'on n'aura pas dans C++0x : il n'y a
que 24 heures dans une journée.

-- Gaby