Apprendre le C++

Loïc Joly wrote on 22/01/2007 20:57:

Je crois que dans mes applications .NET (principalement de l'IHM, avec
les classes de base, plus deux biblitohèques externes, mais toutes
sont comparables en l'occurence), je me retrouve à faire du downcast
depuis Objet [..] vers le type que je manipule directement.

s'il s'agit "principalement d'IHM", ne manque-t-il pas une modélisation
polymorphe des classes en jeu qui éviterait tout (99%) downcast?

Je ne sais pas trop ce que tu entends par là... J'ai mon modèle objet
C++ auquel j'accède par l'intermédiaire interfaces C#, et là, j'ai très
peu de downcast.

Par contre, dans mon IHM, j'utilise une DataGridView .NET, qui dans un
premier temps considère une ligne comme une collection de cellule (type
de base), mais demande que l'on fasse des accès spécifiques en fonction
du type de cellule (une cellule combo-box n'aura pas la même interface
qu'une cellule case à cocher). Dans un second temps, le données
associées à une cellules sont gérées sous formes d'object.

Je ne vois pas dans ces conditions comment ne pas avoir de downcast, à
moins éventuellement de dupliquer en local dans une structure de donnée
typée les informations qui sont dans ma grille, ce qui ne me semble pas
forcément génial non plus.

J'utilise une bibliothèque pour gérer un graphe, qui dans chaque
fonction, chaque évènement... me retourne des node d'une classe de base,
alors que j'ai besoin d'informations en plus disponibles dans mes
classes dérivées, là encore, je ne vois pas comment faire sans donwcast.

De même, bien que les conteneurs génériques existent, les conteneurs
utilisés par les différentes bibliothèques que l'on a dans nos produits
sont non génériques ne serait-ce que par compatibilité avec la version
1.0 du framework, qui ne connaissait pas les génériques => downcast.

Alors, effectivement, si je réécrivais tous les windows form.NET et la
bibliothèque de gestion de graphe qu'on utilise, il y aurait beaucoup
moins de downcast... Mais dans ce cas là, je n'utiliserait assurément
pas un langage .NET pour le faire.

--
Loïc

Loïc Joly wrote on 24/01/2007 02:13:

s'il s'agit "principalement d'IHM", ne manque-t-il pas une
modélisation polymorphe des classes en jeu qui éviterait tout (99%)
downcast?

Je ne sais pas trop ce que tu entends par là...

j'avais cru lire:

je me retrouve à faire du downcast depuis Objet [...]
Je n'ai pas mesuré, mais à vue de nez, je crois ne pas exagérer
en disant que dans ce code, une ligne sur 5 contient un downcast.

par là, je n'entendais pas grand chose, mais je pensais qu'il y avait
des downcast.

J'ai mon modèle objet C++ auquel j'accède par l'intermédiaire
interfaces C#, et là, j'ai très peu de downcast.

mis à part une obfuscation, je ne sais pas ce que peux signifier
"interface cs", je ne cromprends donc pas le point.

Par contre, dans mon IHM, j'utilise une DataGridView .NET, qui dans un
premier temps considère une ligne comme une collection de cellule (type
de base), mais demande que l'on fasse des accès spécifiques en fonction
du type de cellule (une cellule combo-box n'aura pas la même interface
qu'une cellule case à cocher). Dans un second temps, le données
associées à une cellules sont gérées sous formes d'object.

je ne sais pas non plus (et n'est pas envie de savoir) ce qu'est une
"DataGridView.NET" mais si je devais spécialiser une telle ListView
(apparue avec W95, pas .TRUC) en mode 'detail', je définirais simplement
une classe template paramètrée selon le type et nombre de colonnes à
gérer et "surchargerais" son NM_CUSTOMDRAW; j'ai l'habitude de stocker
mes données dans ... des structures de données, pas dans les structures
opaques d'un contrôle d'interface d'un éditeur particulier.

Je ne vois pas dans ces conditions comment ne pas avoir de downcast, à
moins éventuellement de dupliquer en local dans une structure de donnée
typée les informations qui sont dans ma grille, ce qui ne me semble pas
forcément génial non plus.

un seul, dans la wproc associée au control (la ListView) pour récupérer
l'instance depuis le HWND, ensuite que des résolutions virtuelles.

J'utilise une bibliothèque pour gérer un graphe, qui dans chaque
fonction, chaque évènement... me retourne des node d'une classe de base,
alors que j'ai besoin d'informations en plus disponibles dans mes
classes dérivées, là encore, je ne vois pas comment faire sans donwcast.

avec un "node" disposant d'une interface (collection de virtuelles)
pertinente.

De même, bien que les conteneurs génériques existent, les conteneurs
utilisés par les différentes bibliothèques que l'on a dans nos produits
sont non génériques ne serait-ce que par compatibilité avec la version
1.0 du framework, qui ne connaissait pas les génériques => downcast.

.NET n'est pas compatible avec lui-même, c'est facheux, mais est-ce
réellement en rapport notre point ?

Alors, effectivement, si je réécrivais tous les windows form.NET et la
bibliothèque de gestion de graphe qu'on utilise, il y aurait beaucoup
moins de downcast... Mais dans ce cas là, je n'utiliserait assurément
pas un langage .NET pour le faire.

?! on a fait des graphes avant .net, non ?

Sylvain.

Il est etrange de reduire POO - PBO a l'heritage uniquement.

Je ne vois pourtant pas d'autre élément, du moins en C++.
Fonctions virtuelles et polymorphisme d'inclusion n'ont bien sûr pas de
sens sans héritage.

Mathias Gaunard <loufoque@gmail.com> writes:

Fonctions virtuelles et polymorphisme d'inclusion n'ont bien sûr pas de
sens sans héritage.

Du polymorphisme d'inclusion peut tres bien fonctionner avec un typage
structurel (alias duck typing) plutot que nominatif.

La surcharge resolue a l'execution (ce qui est le coeur de la
fonctionnalite des fonctions virtuelles) peut tres bien etre concue sans
qu'il y ait de rapport entre les types, ou simplement un rapport
structurel.

Et avec un typage structurel, il est evident que l'heritage n'est la que
pour l'implementation.

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

J'utilise une bibliothèque pour gérer un graphe, qui dans chaque
fonction, chaque évènement... me retourne des node d'une classe de base,
alors que j'ai besoin d'informations en plus disponibles dans mes
classes dérivées, là encore, je ne vois pas comment faire sans donwcast.

Si tu n'arrives pas à faire ça simplement avec des fonctions virtuelles
et sans downcaster, tu pourrais utiliser des boost.variant, puis
utiliser son système de visiteur potentiellement générique.

Avec de grosses astuces, la même chose peut peut-être se faire sans une
liste fixe de types.
Mais pas de manière aussi performante, bien sûr.

Loïc Joly wrote on 24/01/2007 02:13:

par là, je n'entendais pas grand chose, mais je pensais qu'il y avait
des downcast.

J'ai mon modèle objet C++ auquel j'accède par l'intermédiaire
interfaces C#, et là, j'ai très peu de downcast.

mis à part une obfuscation, je ne sais pas ce que peux signifier
"interface cs",

Le but est de manipuler depuis une IHM en .NET un framework en C++. Il
faut bien à un moment faire le passage entre les notions, et c'est cette
interface C# qui me sert d'isolation entre les deux mondes (avec une
implémentation C++/CLI de l'interfacepour faire le liant).

je ne cromprends donc pas le point.

Le point est que dans le code où j'ai moi même choisi quelles étaient
les classes et leurs relations, je n'ai pas de problème. Le problème,
c'est dans la partie où ma tâche principale est d'utiliser des classes à
usage générique pour faire de l'IHM développées par d'autres, et que je
ne peux pas modifier.

Par contre, dans mon IHM, j'utilise une DataGridView .NET, qui dans un
premier temps considère une ligne comme une collection de cellule
(type de base), mais demande que l'on fasse des accès spécifiques en
fonction du type de cellule (une cellule combo-box n'aura pas la même
interface qu'une cellule case à cocher). Dans un second temps, le
données associées à une cellules sont gérées sous formes d'object.

je ne sais pas non plus (et n'est pas envie de savoir) ce qu'est une
"DataGridView.NET" mais si je devais spécialiser une telle ListView
(apparue avec W95, pas .TRUC) en mode 'detail', je définirais simplement
une classe template paramètrée selon le type et nombre de colonnes à
gérer et "surchargerais" son NM_CUSTOMDRAW;

Le fait est qu'une telle classe est déjà fournie prête à l'emploi dans
.NET, et qu'elle n'est pas templatée, et possède des fonctions
retournant des types de base, mais à downcaster pour être utilisables.

Je pourrais bien entendu choisir de redévelopper une interface plus
fortement typée au dessus de cette classe, mais je perd alors tout
l'intérêt d'utiliser .NET pour mon IHM, et en plus, ma boîte ne me paye
pas pour mettre en place un framework d'IHM, mais pour utiliser un tel
framework pour faire des appliquations qu'elle peut vendre.

j'ai l'habitude de stocker
mes données dans ... des structures de données, pas dans les structures
opaques d'un contrôle d'interface d'un éditeur particulier.

Je stocke aussi mes données là où elles ont du sens. Par contre, pour
récupérer la valeur que l'utilisateur a mise dans une cellule, je
récupère un object, qu'il me faut downcaster en fonction du type de cellule.

J'utilise une bibliothèque pour gérer un graphe, qui dans chaque
fonction, chaque évènement... me retourne des node d'une classe de base,
alors que j'ai besoin d'informations en plus disponibles dans mes
classes dérivées, là encore, je ne vois pas comment faire sans donwcast.

avec un "node" disposant d'une interface (collection de virtuelles)
pertinente.

Le node, ce n'est pas moi qui l'ai écrit. Et son interface n'est pas
suffisante pour tout faire. Le concepteur n'a pas pu penser à tout ce
dont j'aurais besoin. Et donc, par exemple, dans une fonction du graphe
que je surcharge, genre IsLinkPossible(Node n1, Node n2); j'ai besoin de
récupérer des informations spécifiques à mon domaine d'application.
Comment faire sans un moment downcaster n1 et n2 dans des types que j'ai
développés moi et qui possèdent ces informations.

Je ne jette pas la pierre à cette bibliothèque de graphes. J'avoue que
sans template/generics, je serais bien en peine d'écrire une classe node
qui puisse s'adapter aux besoins de l'utilisateur final sans downcast.

De même, bien que les conteneurs génériques existent, les conteneurs
utilisés par les différentes bibliothèques que l'on a dans nos
produits sont non génériques ne serait-ce que par compatibilité avec
la version 1.0 du framework, qui ne connaissait pas les génériques =>
downcast.

.NET n'est pas compatible avec lui-même, c'est facheux, mais est-ce
réellement en rapport notre point ?

En l'occurence, c'est justement sa compatibilité qui est gênante,
puisqu'elle implique de garder les erreurs du passé...

Alors, effectivement, si je réécrivais tous les windows form.NET et la
bibliothèque de gestion de graphe qu'on utilise, il y aurait beaucoup
moins de downcast... Mais dans ce cas là, je n'utiliserait assurément
pas un langage .NET pour le faire.

?! on a fait des graphes avant .net, non ?

Oui. Et ?

--
Loïc

Loïc Joly wrote on 24/01/2007 20:17:

mis à part une obfuscation, je ne sais pas ce que peux signifier
"interface cs",

Le but est de manipuler depuis une IHM en .NET un framework en C++. Il
faut bien à un moment faire le passage entre les notions, et c'est cette
interface C# qui me sert d'isolation entre les deux mondes (avec une
implémentation C++/CLI de l'interface pour faire le liant).

c'est bien ce que j'ai dit: de l'obfuscation!

un framework (de données?) en C++ peut (doit?) se gérer via une IHM C++
coller des glues cli / net / cs pour qu'au final toutes ses (inutiles)
couches adressent une dizaine d'API win32 ne peut pas porter d'autre nom.

je ne cromprends donc pas le point.

Le point est que dans le code où j'ai moi même choisi quelles étaient
les classes et leurs relations, je n'ai pas de problème. Le problème,
c'est dans la partie où ma tâche principale est d'utiliser des classes à
usage générique pour faire de l'IHM développées par d'autres, et que je
ne peux pas modifier.

"generiques" au sens "'template' est déjà pris, inventons un concept
galitineux rien qu'à nous" (c) CLI ?

si tu es obligé d'utiliser ces ""choses"" alors en effet tu es obligé...
je pensais qu'il était imaginable que d'autres fournisseurs de
composants utilisassent des languages moins fermés ou qu'ils ne
basassent pas l'intérêt de leur produit sur le "j'suis-à-la-mode" mais
plus sur la qualité des interfaces / services mises à disposition du
développeur-utilisateur ou encore qu'il était possible de coder ses
propres composants (c'est vrai que nombre d'applications ne sont plus
que des assemblages de composants tiers - ceci n'est pas un critique, en
aucun cas envers vos produits, et parfois cela est économiquement
justifié)(c'est vrai aussi que le "j'suis-à-la-mode" est très important;
j'ai reçu cette semaine une superbe webcam à 4.000 euros de DCS fourni
avec une unique interface cs et un wrapper tout buggé cli; les 2
complètement inutilisables ... sauf pour afficher le p....n de "Form"
qu'ils pensent à tort peut être génial).

Le fait est qu'une telle classe est déjà fournie prête à l'emploi dans
..NET, et qu'elle n'est pas templatée, et possède des fonctions
retournant des types de base, mais à downcaster pour être utilisables.

bah !... si la corde est fournie prête à l'emploi, y'a plus qu'à se
pendre, sur ! ;)

Je pourrais bien entendu choisir de redévelopper une interface plus
fortement typée au dessus de cette classe, mais je perd alors tout
l'intérêt d'utiliser .NET pour mon IHM,

non ?? y'a un intérêt à utiliser .net ??? zut alors, ce détail m'aurait
échappé ?!...

et en plus, ma boîte ne me paye
pas pour mettre en place un framework d'IHM, mais pour utiliser un tel
framework pour faire des appliquations qu'elle peut vendre.

dura economia, sed economia.

Je stocke aussi mes données là où elles ont du sens. Par contre, pour
récupérer la valeur que l'utilisateur a mise dans une cellule, je
récupère un object, qu'il me faut downcaster en fonction du type de
cellule.

mon propos amalgamait à tort.

une autre approche malgré tout possible serait que le composant UI ne
gère que de l'UI; une cellule texte donne un texte, une cellule check,
un boolean, etc; il vous appartient alors (sur modif, validation
globale, ...) de savoir que la cellule (B,3) est une représentation de
la propriété '3' de l'item 'B' de la collection idoine et de modifier
l'attribut (typé) de l'object (typé) selon la valeur (primitive ou
presque) retournée par cette cellule.

Le node, ce n'est pas moi qui l'ai écrit. Et son interface n'est pas
suffisante pour tout faire. Le concepteur n'a pas pu penser à tout ce
dont j'aurais besoin. Et donc, par exemple, dans une fonction du graphe
que je surcharge, genre IsLinkPossible(Node n1, Node n2); j'ai besoin de
récupérer des informations spécifiques à mon domaine d'application.
Comment faire sans un moment downcaster n1 et n2 dans des types que j'ai
développés moi et qui possèdent ces informations.

je comprends bien que /vous ne pouvez pas/ ... vu le composant, mon
point ne commentait pas votre aptitude mais votre possibilité - si le
"graphe" a comme fonction évidente, élémentaire de représenter des
noeuds et de permettre leur connexion, il me parait aussi évident qu'il
devrait offrir une interface 'Node' (à étendre selon les besoins) qui
inclut une virtuelle comme "bool Node::isConnectableTo(const Node&)";
mais l'application de mon point 2 se traduit peut être par le fait qu'il
s'agit plutôt d'un "typedef unsigned long Node;".

?! on a fait des graphes avant .net, non ?

Oui. Et ?

mon point 2 rephrasé: si .net (en soi, ceux qui vendent des trucs basé
sur) n'est pas capable d'offrir une API propre, d'autres langages le
font peut-être.

Sylvain.

Loïc Joly wrote on 24/01/2007 20:17:

mis à part une obfuscation, je ne sais pas ce que peux signifier
"interface cs",

Le but est de manipuler depuis une IHM en .NET un framework en C++. Il
faut bien à un moment faire le passage entre les notions, et c'est
cette interface C# qui me sert d'isolation entre les deux mondes (avec
une implémentation C++/CLI de l'interface pour faire le liant).

c'est bien ce que j'ai dit: de l'obfuscation!

un framework (de données?) en C++ peut (doit?) se gérer via une IHM C++
coller des glues cli / net / cs pour qu'au final toutes ses (inutiles)
couches adressent une dizaine d'API win32 ne peut pas porter d'autre nom.

je ne cromprends donc pas le point.

Le point est que dans le code où j'ai moi même choisi quelles étaient
les classes et leurs relations, je n'ai pas de problème. Le problème,
c'est dans la partie où ma tâche principale est d'utiliser des classes
à usage générique pour faire de l'IHM développées par d'autres, et que
je ne peux pas modifier.

"generiques" au sens "'template' est déjà pris, inventons un concept
galitineux rien qu'à nous" (c) CLI ?

si tu es obligé d'utiliser ces ""choses"" alors en effet tu es obligé...
je pensais qu'il était imaginable que d'autres fournisseurs de
composants utilisassent des languages moins fermés ou qu'ils ne
basassent pas l'intérêt de leur produit sur le "j'suis-à-la-mode" mais
plus sur la qualité des interfaces / services mises à disposition du
développeur-utilisateur ou encore qu'il était possible de coder ses
propres composants

Loin de moi l'idée de contrarier quelq'un capable d'utiliser un
imparfait du subjonctif mais l'interet de CLI est quand même le garbage
collecting. Ce qui est assez confortable quand on design une GUI (cf le
succès de Java pour les interfaces).

Pour programmer en Visual, je suis prêt à faire du CLI rien que pour
profiter de l'environnement Visual Studio et dessiner mes fenêtre en un
rien de temps.

([snip]

Le fait est qu'une telle classe est déjà fournie prête à l'emploi dans
..NET, et qu'elle n'est pas templatée, et possède des fonctions
retournant des types de base, mais à downcaster pour être utilisables.

bah !... si la corde est fournie prête à l'emploi, y'a plus qu'à se
pendre, sur ! ;)

Je pourrais bien entendu choisir de redévelopper une interface plus
fortement typée au dessus de cette classe, mais je perd alors tout
l'intérêt d'utiliser .NET pour mon IHM,

non ?? y'a un intérêt à utiliser .net ??? zut alors, ce détail m'aurait
échappé ?!...

Le même qu'à utiliser PERL, c'est du JIT avec des fonctions de haut
niveau. En plus, il a des capacité d'environement distribué, et des
facilité de programmation concurrente.
ça facilite la vie pour faire un programme dont la durée de vie ne
dépasse pas les 6 mois avant la prochaine release.

Il faut reconnaître qu'il est bien ciblé, la mode étant plutot au fast
scripting de façon à gèrer les demandes et les customisations client (en
théorie du moins).

Michael

Michael DOUBEZ wrote on 24/01/2007 22:54:

Il faut reconnaître qu'il est bien ciblé, la mode étant plutot au fast
scripting de façon à gèrer les demandes et les customisations client (en
théorie du moins).

je suis d'accprd sur ce point - c'est le marché auquel je pensais avec
les termes "assemblages de composants".

la description faite par Loïc me laissait plus penser à une application
métier qu'à une application jetable.

Sylvain.