C++0x et multi-method

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

[...]

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

En effet. Qand je suis arrivé a Parasol Lab en 2003, l'une des premi ères
choses qu'on avait essayé de faire était une proposition (pour C+ +0x) qui
rend plus claire l'équivalence entre functions membres et fonctions
non-membres avec un paramètre en plus. On a rencontré quelques
problèmes de portée et à la fin on avait d'autres feux plus urgents à
eteindre. Quelques aspects se sont retrouvés dans certains papiers, y
compris l'utilisation de « virtual » comme dans le cas de multi-m ethode,
ou la notion de function virtuelle template.

[...]

| > 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 à utili ser cette
| > "extension".
|
| pas si simple en fait, car cela vient se superposer a l'ADL qui n'est
| deja pas tres simple.

Je ne comprends pas le problème avec ADL et pourquoi les gens essaient
de la diaboliser. Je travaille quotidiennement avec un système de
calcul formel (avec une bibliothèque assez large) où c'st ADL qui
règne -- je t'accorde qu'il est aussi équipé de « SFENA E built in ».
Cela marche plutôt bien.

http://www.open-axiom.org/

-- Gaby

Alp Mestan <alpmestan@gmail.com> writes:

[...]

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

Il n'y a que 24 heures dans un journée :-)

-- Gaby

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

[...]

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

:-)

De fait, il y a déjà quelques traces dans C++0x -- « delegat ed
constructors ».

Mais peut-être que la nouvelle génération aura plus de temps et de
resources pour C++1x que les dinausores (je me considère dinausore :-)

-- Gaby

Mathias Gaunard <loufoque@gmail.com> writes:

[...]

| Si tu fais de l'OO, de toutes façons, tu veux sûrement virer
| constructeur de copie et opérateur d'affectation.

Pourquoi ?

[...]

| 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 pla ce les
| templates et de simples fonctions, et de faire de la type erasure pour
| les cas qui ont vraiment besoin d'être dynamiques.

wow. Je me demande pourquoi personne n'y a pensé avant.

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

Que connais-tu de l'approche de programmation des personnes qui
travaillent sur le standard ?

-- Gaby

On 31 mai, 18:03, Mathias Gaunard <loufo...@gmail.com> wrote:

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,

Si vous avez lu aussi bien le papier que ma reponse, on risque de
tourner en rond longtemps...

Alors je me permet de me reciter moi-meme puisque ce dont vous parlez
s'appelle "Curiously recurring template pattern" depuis plus de 15
ans, abrege en CRTP dans mon post precedent.

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

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 le s
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.

Vous devriez essayer d'ecrire un interpreteur, un evaluateur de
feuille Excel ou encore un client de database par exemple et nous
montrer quels concepts vos algorithmes generiques demanderont a leurs
arguments dont les types seront inconnus a la compilation.

a+, ld.

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

Alors je me permet de me reciter moi-meme puisque ce dont vous parlez
s'appelle "Curiously recurring template pattern" depuis plus de 15
ans, abrege en CRTP dans mon post precedent.

Pas du tout.

Je dis simplement qu'au lieu de faire

void do_something(virtual Base1&, virtual Base2);

faire

template<Base1 T1, Base2 T2>
void do_something(T1&, T2&);

C'est bien entendu tout con, mais l'orienté objet est tellement
répandu que les gens ont parfois du mal à penser autrement.

Vous devriez essayer d'ecrire un interpreteur

AST. Cas d'école d'un variant.

un evaluateur de
feuille Excel

Je ne sais pas trop ce que c'est, mais n'est-ce pas un interpréteur ?

ou encore un client de database par exemple

On a besoin de dynamisme où ?
Pour choisir le type de backend à charger à l'exécution ? Cela peut
parfaitement être un simple détail privé et/ou se faire avec de la
type erasure par exemple.

Une présentation intéressante sur l'utilisation du polymorphisme
d'inclusion en tant que détail d'implémentation :
https://admin.adobe.acrobat.com/_a295153/p53888531/

et nous
montrer quels concepts vos algorithmes generiques demanderont a leurs
arguments dont les types seront inconnus a la compilation.

C'est simple : un algorithme nécessite des primitives pour
fonctionner.
Conceptualiser consiste à reconnaître ces primitives pour les
formaliser.

http://www.generic-programming.org/

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

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

[...]

| Si tu fais de l'OO, de toutes façons, tu veux sûrement virer
| constructeur de copie et opérateur d'affectation.

Pourquoi ?

Parce que la sémantique d'entité marche mieux pour la programmation
orientée objet qu'une approche valeur, particulièrement pour les
fameux objets "métier".
C'est avec cette approche que les gens sont formés, et cette approche
est clairement favorisée dans tous les langages du genre C#/Java et
les outils de modélisation, au point où certains disent que l'aliasing
des objets et donc un ramasse-miettes sont des éléments nécessaires
pour faire de l'objet correctement. (ce sont les mêmes d'ailleurs qui
abusent de shared_ptr ou solutions maison similaires)

wow. Je me demande pourquoi personne n'y a pensé avant.

Cf. le "très simple". Je ne fais qu'expliquer des alternatives de
programmation pour contourner le problème, tout en faisant un peu
d'évangélisation.
Pas besoin de prendre de tels airs.

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

Que connais-tu de l'approche de programmation des personnes qui
travaillent sur le standard ?

"Apparemment" dénote une impression personnelle.
Ce que j'en connais, ce sont les papiers postés tous les deux mois sur
open-std.org, le groupe comp.std.c++, et les quelques contacts que
j'ai qui ont participé à des comités.
Les nouveautés, c'est plus des outils de programmation générique ou
fonctionnelle que des fonctionnalités orienté objet. Pas mal de
programmeurs professionnels m'ont d'ailleurs dit qu'ils trouvaient que
C++0x travaille trop sur cet axe et qu'ils ne font qu'empirer le fait
que C++ est un langage d'expert.

La conception elle-même de la bibliothèque standard laisse aussi à
penser que les approches à base de templates sont à préférer à ce lles
à base d'orienté objet.

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

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

Ah, j'avais oublié que fr.comp.lang.c++ c'était pas très constructif.

Qu'apporte cette remarque ? C'est fascinant que je ne me rappelle pas
de détails d'une proposition que j'ai entre-lue il y a un an ou deux ?
Enfin peut être, ça pourrait être fascinant que je puisse me tromper,
avoir une vue différente des choses, ou même être tout simplement con .
Mais bon à quoi ça sert de mettre ça, sans plus d'information, sans
même détailler en une phrase en quoi cela est en contradiction avec ma
conclusion (et quelle conclusion d'ailleurs ?)

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

Il y a une section appelée « related work » -- qui en plus du corps de
l'article  -- discute brievement alternatives ainsi que quelques unes d e
limitations.

Rapport à la choucroute ?
Ne parle pas du tout des alternatives du genre boost.variant que j'ai
conseillées, qui sont bien entendu *plus* rapides que les multi-
méthodes (inlining bien plus facile, switch plutôt que pointeur de
fonction, etc.), et nécessitent moins de mémoire (les meilleurs
optimisateurs ont du mal à éliminer le code mort des fonctions
virtuelles par exemple).

 La section « results » montre a une comparaison entre les
différents systèmes mentionnés où Loki occupe une place mémorab le.

Ce qui n'a rien de surprenant, et n'a rien à voir avec la raison pour
laquelle j'ai cité Loki. J'ai parlé de restrictions d'utilisation, pas
de l'efficacité.
Mais là encore, c'est pas mal biaisé, les restrictions d'utilisation
du static visitor de loki sont quand même beaucoup moins strictes que
celles impliquées par l'usage d'un variant.

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

Lister l'ensemble des classes dans une type list n'a aucun impact sur
la taille du code ou le temps d'exécution, puisqu'il s'agit
d'informations déterminées uniquement à la compilation.

Enfin bref, vous n'avez sûrement pas répondu à la bonne citation.

| Après la solution de Loki est lente car linéaire, mais elle fonctio nne
| 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 constan t
| 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 programm ation
  # propre, efficace, donnant lieu à des programmes maintenables.  

Je parle d'une astuce expérimentale pour augmenter l'efficacité (qui
n'est pas forcément si bien que ça, c'est à tester, et qui nécessit e
d'associer à chaque type son nom sous la forme d'une chaîne compile-
time), et on me donne des critères de qualité de base ?

L'OP avait pourtant dit qu'il était satisfait de la solution de Loki,
à part au niveau de la performance. Donc un début de solution pour la
performance je propose.

| À part ça selon moi l'orienté objet est un paradigme assez mauvai s,
est-ce un postulat ?

"Selon moi" indique généralement une opinion personnelle.

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

[...]

Évangélisme tout ça, vous comprenez ?
Il n'y a rien de choquant à ce que je conseille aux gens des
alternatives de programmation que je préfère moi et qui qui répondrai t
à leurs problèmes.

Je ne suis pas sur Internet pour donner un avis objectif, ni fournir
une analyse complète.

Mathias Gaunard <loufoque@gmail.com> writes:

| On 31 mai, 18:13, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
|
| > | 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.
|
| Ah, j'avais oublié que fr.comp.lang.c++ c'était pas très c onstructif.

Tu as absolument raison et tes messages (y compris celui auquel je
réponds) en sont des évidences palpables : tu as commencé à pontifier
avec des opinions fortes sur une proposition que tu sembles vaguement
avoir lue.

Une approche constructive aurait été :
(1) lire la proposition -- au lieu de te plaindre de voir un lien sur
ce dont on parle.

(2) La télécharger, la lire, et la comprendre -- s'il y a des p oints
spécifiques qui restent obscure, demander des éclaircissemn ts.

En particulier, le lien avec des travaux existents (related work).
Étudier les resultats concrets de performance (au lieu de
théoriser). Ne pas oublier que les gens qui ont fait la
proposition ont quand même *concretement travaillé* sur une
implémentation (expérimentale) au lieu juste de théori ser

(3) Si tu trouves des defauts, identifier les et proposer des
améliorations.

[...]

| Je ne suis pas sur Internet pour donner un avis objectif, ni fournir
| une analyse complète.

Un euphémisme pour « je ne suis pas sur Internet pour être t rès
constructif » ?

-- Gaby

Mathias Gaunard <loufoque@gmail.com> writes:

| On 31 mai, 18:41, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| > Mathias Gaunard <loufo...@gmail.com> writes:
| >
| > [...]
| >
| > | Si tu fais de l'OO, de toutes façons, tu veux sûrement virer
| > | constructeur de copie et opérateur d'affectation.
| >
| > Pourquoi ?
|
| Parce que la sémantique d'entité marche mieux pour la programma tion
| orientée objet qu'une approche valeur, particulièrement pour les
| fameux objets "métier".

J'ai une bibliothèque qui utilise ce qu'on appelle la programmation
orientée objet et qui marche très bien, sans que j'ai à vire r quoi que
ce soit. C'est un ensemble de classes C++ permettant de représenter d es
programmes C++. L'utilisateur se voit présenter une interface, qui ne
contient que des classes abstraites. En quoi virer les constructeur de
copie et opérateurs d'affectation aurait fait « marcher mieux  » ?

[...]

| > | Apparemment c'est plus cette approche de programmation qui plaît aux
| > | gens qui travaillent sur le standard, et l'orienté objet est don c un
| > | peu délaissé.
| >
| > Que connais-tu de l'approche de programmation des personnes qui
| > travaillent sur le standard ?
|
| "Apparemment" dénote une impression personnelle.
| Ce que j'en connais, ce sont les papiers postés tous les deux mois s ur
| open-std.org, le groupe comp.std.c++, et les quelques contacts que
| j'ai qui ont participé à des comités.
^^^^^^^^^^^^^^

« des comités C++ » ?

| Les nouveautés, c'est plus des outils de programmation génà ©rique ou
| fonctionnelle que des fonctionnalités orienté objet. Pas mal de
| programmeurs professionnels m'ont d'ailleurs dit qu'ils trouvaient que
| C++0x travaille trop sur cet axe et qu'ils ne font qu'empirer le fait
| que C++ est un langage d'expert.

Cela n'indique pas forcément une préférence d'approche de
programmation. Cela peut indiquer qu'ils travaillent sur des aspects
qu'ils trouvent moins bien supporté par le C++ actuel.
(Prend cela comme une information de première main, pas juste une
impression).

| La conception elle-même de la bibliothèque standard laisse auss i à
| penser que les approches à base de templates sont à préf érer à celles
| à base d'orienté objet.

C'est beaucoup plus nuancé que cela.

-- Gaby