J'ai lu avec grand intérêt l'article "Concepts for C++0x" mentionné dans
un thread récent.
Habituellement, je ne m'intéresse pas aux évolutions du langage car
elles ne me concernent qu'à un relativement long terme, mais là, j'ai
l'impression qu'un mouvement de fond relatif aux paradygmes du C++ prend
une certaine ampleur.
Et ce mouvement m'amène à quelques interrogations.
La plupart des développeurs que je cotoie programment en C++ dans un
style orienté objet très proche de ce que l'on trouve en Java.
Je prends un exemple classique de Bridge+Factory pour illustrer mon propos.
On a typiquement une hiérarchie d'implémentations :
| class DocumentDisplay {
| virtual ~DocumentDisplay();
| virtual void drawText( int x, int y, std::string const &text ) = 0;
| virtual void drawLine( int x1, int y1, int x2, int y2 ) = 0;
| };
|
| class GraphicDocumentDisplay : public DocumentDisplay {
| virtual void drawText( int x, int y, std::string const &text );
| virtual void drawLine( int x1, int y1, int x2, int y2 );
| };
|
| class TextDocumentDisplay : public DocumentDisplay {
| ...
une hiérarchie d'abstractions qui utilisent les implémentations :
|
| class Document {
| public:
| Document( DocumentDisplay *display ) : display_(display) {}
| virtual ~Document();
|
| void drawFrame( int x, int y, int w, int h, std::string const &title ) {
| display_->drawLine( x, y, x+w, y );
| display_->drawLine( x, y+h, x+w, y+h );
| display_->drawText( x, y, title );
| }
| private:
| DocumentDisplay *display_;
| };
|
| class Memo : public Document {
| public:
| Memo( DocumentDisplay *display ) : Document(display) {}
| void drawSummary() { drawFrame( 0, 0, 150, 100, "Summary" ); }
| };
|
| class Invoice : public Document {
| ...
une hiérarchie de fabriques pour instancier tout ça :
| class DocumentFactory {
| public:
| virtual ~DocumentFactory() {}
| virtual Memo *createMemo() = 0;
| virtual Invoice *createInvoice() = 0;
| };
|
| class GraphicDocumentFactory : public DocumentFactory {
| public:
| virtual Memo *createMemo() { return new Memo( new
GraphicDocumentDisplay ); }
| virtual Invoice *createInvoice() { return new Invoice( new
GraphicDocumentDisplay ); }
| };
et je rajoute un programme principal pour utiliser le tout :
| class Application {
| public:
| Application( DocumentFactory *factory ) : factory_(factory) {}
|
| void run() {
| Memo *memo = factory_->createMemo();
| memo->drawSummary();
| }
| private:
| DocumentFactory *factory_;
| };
|
| int main() {
| Application app( new GraphicDocumentFactory );
| app.run();
| }
En pratique, ça a une tête un peu différente (avec le RAII par exemple),
mais l'idée des hiérarchie de classes est là.
Depuis quelques temps se répand la programmation générique qui permet de
faire la même chose avec (en général) moins de lignes de code.
Les implémentations deviennent des "policy" et n'ont plus besoin de
classe de base
| class GraphicDocumentDisplay {
| virtual void drawText( int x, int y, std::string const &text );
| virtual void drawLine( int x1, int y1, int x2, int y2 );
| };
Les abstractions sont paramétrées par la policy.
On garde un héritage pour partager l'implémentation :
| template <class DOCDISP>
| class Document {
| public:
| virtual ~Document() {}
|
| void drawFrame( int x, int y, int w, int h, std::string const &title ) {
| display_.drawLine( x, y, x+w, y );
| display_.drawLine( x, y+h, x+w, y+h );
| display_.drawText( x, y, title );
| }
| private:
| DOCDISP display_;
| };
|
| template <class DOCDISP>
| class Memo : public Document<DOCDISP> {
| public:
| void drawSummary() { drawFrame( 0, 0, 150, 100, "Summary" ); }
| };
Dans un cas aussi simple, on oublie la factory et on paramètre
directement l'application :
| template <class DOCDISP>
| class Application {
| public:
| void run() {
| Memo<DOCDISP> memo;
| memo.drawSummary();
| }
| };
|
| int main() {
| Application<GraphicDocumentDisplay> app;
| app.run();
| }
Une telle approche est actuellement plutôt prisée par des personnes qui
connaissent bien le langage et est donc globalement plutôt minoritaire.
Parmi les raisons de cette situation je vois :
- la forte présence de langages comme Java ou C# qui ne proposent pas
cette approche (les versions "Generic" restent anecdotiques) et donc le
grand nombre de personnes qui font du C++ comme ils font du Java
- le faible support des templates par certains compilateurs jusqu'à une
période récente (cf les interrogations récurrentes relatives au support
des templates dans VC6)
- un support méthodologique peu adapté (UML se prête beaucoup plus à
décrire des héritages que de paramétrages)
- une complexité de mise au point d'une approche à base de templates
(typage structurel, définitions statiques, ...)
Sur ce, je découvre les "concepts" (dont je ne pense pas avoir saisi le
dixième des utilisations et implications) qui me laissent supposer que,
dans un avenir plus ou moins proche, on pourrait écrire les choses de
manière plus explicites.
Les policy pourraient être nommées et contrôlées avant usage. Si j'ai
bien compris les notions et syntaxes proposées dans l'article, cela
donnerait quelque chose comme :
| template <DOCDISP>
| concept DisplaysDocuments {
| void DOCDISP::drawText( int x, int y, std::string const &text );
| void DOCDISP::drawLine( int x1, int y1, int x2, int y2 );
| };
|
| class GraphicDocumentDisplay {
| public:
| void drawText( int x, int y, std::string const &text );
| void drawLine( int x1, int y1, int x2, int y2 );
| };
|
| model DisplaysDocuments<GraphicDocumentDisplay>;
Et j'ai même l'impression que des implémentations par défaut définies au
niveau des concepts pourraient rendre obsolète une grand pan de
l'utilisation de l'héritage.
En écrivant par exemple ce qui suit, j'ai l'impression d'avoir
entièrement réécrit l'exemple vu précédemment sans utiliser aucun
héritage C++ mais avec l'impression d'avoir quand même fait de l'"objet"
(s'il est encore possible de définir ce terme...) mais "autrement".
| template <DOC>
| concept IsDocument {
| typename doc_display;
| require DisplaysDocuments<doc_display>;
|
| doc_display &DOC::display();
|
| void DOC::drawFrame( int x, int y, int w, int h, std::string const
&title ) {
| display().drawLine( x, y, x+w, y );
| display().drawLine( x, y+h, x+w, y+h );
| display().drawText( x, y, title );
| }
| };
|
| template <class DOCDISP>
| class Memo {
| public:
| typedef DOCDISP doc_display;
| doc_display &display() { return display_; }
|
| void drawSummary() { drawFrame( 0, 0, 150, 100, "Summary" ); }
| private:
| DOCDISP display_;
| };
|
| template <class DOCDISP>
| model IsDocument< Memo<DOCDISP> >;
Pour ceux qui auront eu le courage de lire jusqu'ici, j'aimerais savoir
s'ils pensent :
- que je n'ai rien compris aux "concepts" ?
- que ces notions vont avoir un impact technique majeur sur l'écriture
de code en C++ ?
- que ces notions vont avoir un impact sociologique majeur sur le
développement en C++ ?
Je suis plus particulièrement intéressé par l'aspect sociologique des
choses.
J'ai l'impression d'être face à une évolution du même ordre de grandeur
que le passage du C au C++.
Pour tout dire, j'ai même l'impression que le terme C++ n'est conservé
que pour des raisons marketing (la "marque" est déja connue, appréciée,
possède une base de consommateurs, ...)
Il est toujours possible d'écrire du C avec un compilateur C++ mais, sur
une période d'environ 10 ans (en gros les années 90) on est passé d'une
approche majoritaire en termes de structures/procédures a une approche
majoritaire classes/héritages/associations.
Cela a impliqué un changement de principes de modélisation, un
changement de techniques d'écriture de code mais surtout un changement
de mentalité.
Et quand je regarde les efforts qu'il a fallu déployer pour que
l'ensemble des intervenants en arrive à penser les développements plus
ou moins de la même manière, j'ai un peu l'impression, en voyant ces
nouvelles notions qui se profilent à l'horizon, que nous ne sommes pas
au bout de nos peines...
| Ma perception est que la mode est en train de s'etendre au dela des | news et des cercles "inities", mais je peux me tromper.
oui, malheureusement sans voir le fond de l'histoire :-( je vois de plus en plus de policy partout avec des myriades de paramètres et des smart pointers dans tous les coins, même et surtout là où n'est pas pertinent. :-(
[...]
| > Mais je ne suis pas sûr que ça change quelque chose du fond. Je n'ai | > pas trop suivi les histoires de « concepts », mais est-ce qu'il ne | > serait pas un peu une façon de définir des contrats pour le | > polymorphisme paramètrique ? | | Ca depend ce que tu entends par contrats. C'est une facon de | specifier les contraintes que doivent respecter les arguments | templates et ca permet au moins d'une part de verifier que le code | template n'utilise pas autre chose, d'autre part de verifier que les | clients respectent bien ces contraintes meme si pour le moment elles | ne sont pas utilisees. En prime ca doit permettre de generer des | messages d'erreurs plus comprehensible. Je n'ai pas encore compris | comment ca permet de faciliter l'ecriture de template -- en | particulier l'allusion a SFINAE) sauf si on essaie de faire mon | deuxieme point (verifier que le code utilisateur respecte les | contraintes) avec les possibilites actuelles.
Surcharger les templates. Actuellement, on ne peut le faire que pour les fonctions et sur nombre de paramètres. SFINEA permet une approximation, mais uniquement au prix d'une obfuscation redoutable. Nombre d'algorithmes de la stl se terminent pas _if parce qu'on ne sait pas exprimer le fait que quelque chose est un predicat et l'autre juste une valeur (que l'on cherche).
| | A partir du moment ou on nomme des contraintes, on peut les reutiliser | (ce qui n'est pas possible avec une autre technique possibe: etendre | les parametres templates pour pouvoir y mettre avec des valeurs par | defaut tout ce qui est utilise) et les manipuler. Je ne sais pas | quelles seront les manipulations permises (les valeurs par defaut) ni | ce qu'elles apporteront. On peut avoir une "surprise" du genre de | celle apportee par le fait que les templates sont deja un langage | complet et donc autre chose que des macros avec du typage fort. J'ai | l'impression que l'approche de Gaby et Bjarne est d'explorer justement | les differentes solutions pour choisir la plus coherente et la plus | expressive.
Exact.
Nous avons essayé de trouver des exemples « tests ». Par exemple, essayer d'exprimer merge() correctement, ou essayer de modeliser des structures mathématiques -- pour ne pas s'enfermer dans le monde des itérateurs.
Comme exemple sympatique, il y la manipulation de types auxquels ont a attache des unites physiques (une generalisation de ce que Barton & Nackman ont proposes dans leur livre)? Par ce que la vous gagneriez pleins de fideles ;-)
a+, ld.
Gabriel Dos Reis wrote:
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| Ma perception est que la mode est en train de s'etendre au dela des
| news et des cercles "inities", mais je peux me tromper.
oui, malheureusement sans voir le fond de l'histoire :-(
je vois de plus en plus de policy partout avec des myriades de
paramètres et des smart pointers dans tous les coins, même et surtout
là où n'est pas pertinent.
:-(
[...]
| > Mais je ne suis pas sûr que ça change quelque chose du fond. Je n'ai
| > pas trop suivi les histoires de « concepts », mais est-ce qu'il ne
| > serait pas un peu une façon de définir des contrats pour le
| > polymorphisme paramètrique ?
|
| Ca depend ce que tu entends par contrats. C'est une facon de
| specifier les contraintes que doivent respecter les arguments
| templates et ca permet au moins d'une part de verifier que le code
| template n'utilise pas autre chose, d'autre part de verifier que les
| clients respectent bien ces contraintes meme si pour le moment elles
| ne sont pas utilisees. En prime ca doit permettre de generer des
| messages d'erreurs plus comprehensible. Je n'ai pas encore compris
| comment ca permet de faciliter l'ecriture de template -- en
| particulier l'allusion a SFINAE) sauf si on essaie de faire mon
| deuxieme point (verifier que le code utilisateur respecte les
| contraintes) avec les possibilites actuelles.
Surcharger les templates. Actuellement, on ne peut le faire que pour
les fonctions et sur nombre de paramètres. SFINEA permet une
approximation, mais uniquement au prix d'une obfuscation redoutable.
Nombre d'algorithmes de la stl se terminent pas _if parce qu'on ne
sait pas exprimer le fait que quelque chose est un predicat et l'autre
juste une valeur (que l'on cherche).
|
| A partir du moment ou on nomme des contraintes, on peut les reutiliser
| (ce qui n'est pas possible avec une autre technique possibe: etendre
| les parametres templates pour pouvoir y mettre avec des valeurs par
| defaut tout ce qui est utilise) et les manipuler. Je ne sais pas
| quelles seront les manipulations permises (les valeurs par defaut) ni
| ce qu'elles apporteront. On peut avoir une "surprise" du genre de
| celle apportee par le fait que les templates sont deja un langage
| complet et donc autre chose que des macros avec du typage fort. J'ai
| l'impression que l'approche de Gaby et Bjarne est d'explorer justement
| les differentes solutions pour choisir la plus coherente et la plus
| expressive.
Exact.
Nous avons essayé de trouver des exemples « tests ». Par exemple,
essayer d'exprimer merge() correctement, ou essayer de modeliser
des structures mathématiques -- pour ne pas s'enfermer dans le
monde des itérateurs.
Comme exemple sympatique, il y la manipulation de types auxquels ont a
attache des unites physiques (une generalisation de ce que Barton &
Nackman ont proposes dans leur livre)? Par ce que la vous gagneriez
pleins de fideles ;-)
| Ma perception est que la mode est en train de s'etendre au dela des | news et des cercles "inities", mais je peux me tromper.
oui, malheureusement sans voir le fond de l'histoire :-( je vois de plus en plus de policy partout avec des myriades de paramètres et des smart pointers dans tous les coins, même et surtout là où n'est pas pertinent. :-(
[...]
| > Mais je ne suis pas sûr que ça change quelque chose du fond. Je n'ai | > pas trop suivi les histoires de « concepts », mais est-ce qu'il ne | > serait pas un peu une façon de définir des contrats pour le | > polymorphisme paramètrique ? | | Ca depend ce que tu entends par contrats. C'est une facon de | specifier les contraintes que doivent respecter les arguments | templates et ca permet au moins d'une part de verifier que le code | template n'utilise pas autre chose, d'autre part de verifier que les | clients respectent bien ces contraintes meme si pour le moment elles | ne sont pas utilisees. En prime ca doit permettre de generer des | messages d'erreurs plus comprehensible. Je n'ai pas encore compris | comment ca permet de faciliter l'ecriture de template -- en | particulier l'allusion a SFINAE) sauf si on essaie de faire mon | deuxieme point (verifier que le code utilisateur respecte les | contraintes) avec les possibilites actuelles.
Surcharger les templates. Actuellement, on ne peut le faire que pour les fonctions et sur nombre de paramètres. SFINEA permet une approximation, mais uniquement au prix d'une obfuscation redoutable. Nombre d'algorithmes de la stl se terminent pas _if parce qu'on ne sait pas exprimer le fait que quelque chose est un predicat et l'autre juste une valeur (que l'on cherche).
| | A partir du moment ou on nomme des contraintes, on peut les reutiliser | (ce qui n'est pas possible avec une autre technique possibe: etendre | les parametres templates pour pouvoir y mettre avec des valeurs par | defaut tout ce qui est utilise) et les manipuler. Je ne sais pas | quelles seront les manipulations permises (les valeurs par defaut) ni | ce qu'elles apporteront. On peut avoir une "surprise" du genre de | celle apportee par le fait que les templates sont deja un langage | complet et donc autre chose que des macros avec du typage fort. J'ai | l'impression que l'approche de Gaby et Bjarne est d'explorer justement | les differentes solutions pour choisir la plus coherente et la plus | expressive.
Exact.
Nous avons essayé de trouver des exemples « tests ». Par exemple, essayer d'exprimer merge() correctement, ou essayer de modeliser des structures mathématiques -- pour ne pas s'enfermer dans le monde des itérateurs.
Comme exemple sympatique, il y la manipulation de types auxquels ont a attache des unites physiques (une generalisation de ce que Barton & Nackman ont proposes dans leur livre)? Par ce que la vous gagneriez pleins de fideles ;-)
a+, ld.
Gabriel Dos Reis
Laurent Deniau writes:
[...]
| > Nous avons essayé de trouver des exemples « tests ». Par exemple, | > essayer d'exprimer merge() correctement, ou essayer de modeliser | > des structures mathématiques -- pour ne pas s'enfermer dans le | > monde des itérateurs. | | Comme exemple sympatique, il y la manipulation de types auxquels ont a | attache des unites physiques (une generalisation de ce que Barton & | Nackman ont proposes dans leur livre)? Par ce que la vous gagneriez | pleins de fideles ;-)
Je crois que si on peut simplement et élégamment encoder des structures comme monoïde, semi-groupe, groupe, anneau, coprs, algèbre, espace vectoriel alors on peut représenter ce dont tu parles.
Quand on fait cet exercice, on se rend compte que la notion de « types associés » est juste une facette d'une notion plus fondamentale qui est « constantes associées » -- constante au sens large, e.g. valeurs constantes, fonctions, types, ...
-- Gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
[...]
| > Nous avons essayé de trouver des exemples « tests ». Par exemple,
| > essayer d'exprimer merge() correctement, ou essayer de modeliser
| > des structures mathématiques -- pour ne pas s'enfermer dans le
| > monde des itérateurs.
|
| Comme exemple sympatique, il y la manipulation de types auxquels ont a
| attache des unites physiques (une generalisation de ce que Barton &
| Nackman ont proposes dans leur livre)? Par ce que la vous gagneriez
| pleins de fideles ;-)
Je crois que si on peut simplement et élégamment encoder des
structures comme monoïde, semi-groupe, groupe, anneau, coprs,
algèbre, espace vectoriel alors on peut représenter ce dont tu parles.
Quand on fait cet exercice, on se rend compte que la notion de
« types associés » est juste une facette d'une notion plus fondamentale
qui est « constantes associées » -- constante au sens large,
e.g. valeurs constantes, fonctions, types, ...
| > Nous avons essayé de trouver des exemples « tests ». Par exemple, | > essayer d'exprimer merge() correctement, ou essayer de modeliser | > des structures mathématiques -- pour ne pas s'enfermer dans le | > monde des itérateurs. | | Comme exemple sympatique, il y la manipulation de types auxquels ont a | attache des unites physiques (une generalisation de ce que Barton & | Nackman ont proposes dans leur livre)? Par ce que la vous gagneriez | pleins de fideles ;-)
Je crois que si on peut simplement et élégamment encoder des structures comme monoïde, semi-groupe, groupe, anneau, coprs, algèbre, espace vectoriel alors on peut représenter ce dont tu parles.
Quand on fait cet exercice, on se rend compte que la notion de « types associés » est juste une facette d'une notion plus fondamentale qui est « constantes associées » -- constante au sens large, e.g. valeurs constantes, fonctions, types, ...
-- Gaby
Olivier Azeau
Jean-Marc Bourguet wrote:
Gabriel Dos Reis writes:
Jean-Marc Bourguet writes:
[...]
| Ma perception est que la mode est en train de s'etendre au dela des | news et des cercles "inities", mais je peux me tromper.
oui, malheureusement sans voir le fond de l'histoire :-(
Je crois que plus que de capacites nouvelles en C++, ce dont certains manquent est une connaissance d'autres langages (et Java et C# ne comptent pas).
Mais là j'ai l'impression que le problème est énoncé à l'envers.
Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette galaxie. Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Que l'on puisse ou non rajouter des capacités qui n'ont plus grand chose en commun avec la programmation objet telle que pratiquée dans cette galaxie n'a en fait que peu d'importance : si ces capacités sont rajoutées dans C++, cela prendra plus d'une décennie avant que les pratiques puissent évoluer.
C'est comme si tu avais dit il y a 20 ans que plus que de capacités nouvelles en C, ce dont certains manquent est une connaissance d'autres langages (et Basic et Fortran ne comptent pas)
je vois de plus en plus de policy partout avec des myriades de paramètres et des smart pointers dans tous les coins, même et surtout là où n'est pas pertinent.
C'est où "partout" ? Pour ma part, j'en ai mis une pour la première fois il y a 2 jours (et encore ça compte pas : c'était juste sur usenet)
La maniere dont l'OP a utilise "policy" est assez revelatrice de ca. J'aimerais avoir le temps de repondre au premier message en detail...
Bonne initiative ;-) (c'est un peu pour ça que je l'ai posté d'ailleurs...)
L'attitude "tout pointeur non smart devrait etre supprime en dehors de l'implementation des smart pointeurs" devient aussi parfois penible.
et __gc, c'est pénible ?
Jean-Marc Bourguet wrote:
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| Ma perception est que la mode est en train de s'etendre au dela des
| news et des cercles "inities", mais je peux me tromper.
oui, malheureusement sans voir le fond de l'histoire :-(
Je crois que plus que de capacites nouvelles en C++, ce dont certains
manquent est une connaissance d'autres langages (et Java et C# ne
comptent pas).
Mais là j'ai l'impression que le problème est énoncé à l'envers.
Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie Java,
C#, VB, Php, etc. et le C++ fait factuellement partie de cette galaxie.
Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Que l'on puisse ou non rajouter des capacités qui n'ont plus grand chose
en commun avec la programmation objet telle que pratiquée dans cette
galaxie n'a en fait que peu d'importance : si ces capacités sont
rajoutées dans C++, cela prendra plus d'une décennie avant que les
pratiques puissent évoluer.
C'est comme si tu avais dit il y a 20 ans que plus que de capacités
nouvelles en C, ce dont certains manquent est une connaissance d'autres
langages (et Basic et Fortran ne comptent pas)
je vois de plus en plus de policy partout avec des myriades de
paramètres et des smart pointers dans tous les coins, même et
surtout là où n'est pas pertinent.
C'est où "partout" ?
Pour ma part, j'en ai mis une pour la première fois il y a 2 jours (et
encore ça compte pas : c'était juste sur usenet)
La maniere dont l'OP a utilise "policy" est assez revelatrice de ca.
J'aimerais avoir le temps de repondre au premier message en detail...
Bonne initiative ;-) (c'est un peu pour ça que je l'ai posté d'ailleurs...)
L'attitude "tout pointeur non smart devrait etre supprime en dehors de
l'implementation des smart pointeurs" devient aussi parfois penible.
| Ma perception est que la mode est en train de s'etendre au dela des | news et des cercles "inities", mais je peux me tromper.
oui, malheureusement sans voir le fond de l'histoire :-(
Je crois que plus que de capacites nouvelles en C++, ce dont certains manquent est une connaissance d'autres langages (et Java et C# ne comptent pas).
Mais là j'ai l'impression que le problème est énoncé à l'envers.
Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette galaxie. Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Que l'on puisse ou non rajouter des capacités qui n'ont plus grand chose en commun avec la programmation objet telle que pratiquée dans cette galaxie n'a en fait que peu d'importance : si ces capacités sont rajoutées dans C++, cela prendra plus d'une décennie avant que les pratiques puissent évoluer.
C'est comme si tu avais dit il y a 20 ans que plus que de capacités nouvelles en C, ce dont certains manquent est une connaissance d'autres langages (et Basic et Fortran ne comptent pas)
je vois de plus en plus de policy partout avec des myriades de paramètres et des smart pointers dans tous les coins, même et surtout là où n'est pas pertinent.
C'est où "partout" ? Pour ma part, j'en ai mis une pour la première fois il y a 2 jours (et encore ça compte pas : c'était juste sur usenet)
La maniere dont l'OP a utilise "policy" est assez revelatrice de ca. J'aimerais avoir le temps de repondre au premier message en detail...
Bonne initiative ;-) (c'est un peu pour ça que je l'ai posté d'ailleurs...)
L'attitude "tout pointeur non smart devrait etre supprime en dehors de l'implementation des smart pointeurs" devient aussi parfois penible.
et __gc, c'est pénible ?
Olivier Azeau
Ivan Vecerina wrote:
Oui, mais ce qu'il faut regarder est quelle portion du code est commune entre les deux versions du document:
Version OO: +----------> GraphicDisplay Document ----+ (dispatch dynamique en run-time) +----------> Text Display Il n'existe qu'une version du code de 'Document'.
Oui
Version Générique (template simple ou concept):
DocumentGraphique -----------> GraphicDisplay
DocumentTexte -----------> TextDisplay
Oui
Le code de 'Document' est intégralement dupliqué. Ceci peut apporter un gain de performance à l'exécution en au coût d'une quantité de code supplémentaire. Un gain aussi si seulement un des deux types de documents doit être compilé dans une application.
Et alors ?
|Mais justement, est-ce que la problematique du choix de l'approche |n'est pas principalement due aux difficultés de mise en oeuvre du |"polymorphisme de compilation" dans l'état actuel des templates ?
Dans certains cas peut-être. Le choix d'une forme de polymorphisme ou de l'autre devrait avant tout dépendre de critères de design et de performance. L'orienté-objet dynamique total (pex SmallTalk) permet de tout faire, mais a des coût excessifs en terme de performance. (C'est pourquoi, en Java, int/etc ne sont pas des objets). D'ou la puissance d'un polymorphisme traduit en phase de compilation (= programmation générique).
Le critère de performance, je l'oublie car dans la plupart des applis C++ (et surtout dans toutes celles que je connais) le goulot d'étranglement ne vient pas du polymorphisme dynamique.
Les "critères de design", c'est quoi ?
Le fait que la programmation générique devienne plus accessible pourrait permettre un choix plus libre entre ces deux niveaux de polymorphisme.
Comment ?
|> Je pense simplement que le C++ est un language complexe car il |> intègre nombre de |> concepts et de paradigmes de programmation. Ceci le rend |> puissant, mais aussi complexe et plus difficile à aborder. | |Ok. Donc en rajoutant de nouvelles notions qui simplifient une |certaine approche du développement, on complexifie la mise en |oeuvre d'une utilisation de C++.
Exactement. Une meilleure intégration d'autres paradigmes (p.ex. programmation fonctionnelle, introspection, etc) est également envisagée en C++. Il serait judicieux de trouver une approche et une syntaxe unifiée pour intégrer tous ces paradigmes (et qui soit un peu moins barbare que les templates actuels...).
Ok pour tout ça mais en pratique comment on fait pour ne pas complexifier la mise en oeuvre du langage ? Aujourd'hui c'est plutôt simple car les templates sont en fait relativement peu utilisés.
Ivan Vecerina wrote:
Oui, mais ce qu'il faut regarder est quelle portion du code
est commune entre les deux versions du document:
Version OO:
+----------> GraphicDisplay
Document ----+ (dispatch dynamique en run-time)
+----------> Text Display
Il n'existe qu'une version du code de 'Document'.
Oui
Version Générique (template simple ou concept):
DocumentGraphique -----------> GraphicDisplay
DocumentTexte -----------> TextDisplay
Oui
Le code de 'Document' est intégralement dupliqué.
Ceci peut apporter un gain de performance à l'exécution
en au coût d'une quantité de code supplémentaire. Un gain
aussi si seulement un des deux types de documents doit
être compilé dans une application.
Et alors ?
|Mais justement, est-ce que la problematique du choix de l'approche
|n'est pas principalement due aux difficultés de mise en oeuvre du
|"polymorphisme de compilation" dans l'état actuel des templates ?
Dans certains cas peut-être. Le choix d'une forme de polymorphisme
ou de l'autre devrait avant tout dépendre de critères de design
et de performance. L'orienté-objet dynamique total (pex SmallTalk)
permet de tout faire, mais a des coût excessifs en terme de
performance. (C'est pourquoi, en Java, int/etc ne sont pas
des objets). D'ou la puissance d'un polymorphisme traduit
en phase de compilation (= programmation générique).
Le critère de performance, je l'oublie car dans la plupart des applis
C++ (et surtout dans toutes celles que je connais) le goulot
d'étranglement ne vient pas du polymorphisme dynamique.
Les "critères de design", c'est quoi ?
Le fait que la programmation générique devienne plus accessible
pourrait permettre un choix plus libre entre ces deux niveaux
de polymorphisme.
Comment ?
|> Je pense simplement que le C++ est un language complexe car il
|> intègre nombre de
|> concepts et de paradigmes de programmation. Ceci le rend
|> puissant, mais aussi complexe et plus difficile à aborder.
|
|Ok. Donc en rajoutant de nouvelles notions qui simplifient une
|certaine approche du développement, on complexifie la mise en
|oeuvre d'une utilisation de C++.
Exactement.
Une meilleure intégration d'autres paradigmes (p.ex.
programmation fonctionnelle, introspection, etc) est
également envisagée en C++. Il serait judicieux de
trouver une approche et une syntaxe unifiée pour
intégrer tous ces paradigmes (et qui soit un peu
moins barbare que les templates actuels...).
Ok pour tout ça mais en pratique comment on fait pour ne pas
complexifier la mise en oeuvre du langage ?
Aujourd'hui c'est plutôt simple car les templates sont en fait
relativement peu utilisés.
Oui, mais ce qu'il faut regarder est quelle portion du code est commune entre les deux versions du document:
Version OO: +----------> GraphicDisplay Document ----+ (dispatch dynamique en run-time) +----------> Text Display Il n'existe qu'une version du code de 'Document'.
Oui
Version Générique (template simple ou concept):
DocumentGraphique -----------> GraphicDisplay
DocumentTexte -----------> TextDisplay
Oui
Le code de 'Document' est intégralement dupliqué. Ceci peut apporter un gain de performance à l'exécution en au coût d'une quantité de code supplémentaire. Un gain aussi si seulement un des deux types de documents doit être compilé dans une application.
Et alors ?
|Mais justement, est-ce que la problematique du choix de l'approche |n'est pas principalement due aux difficultés de mise en oeuvre du |"polymorphisme de compilation" dans l'état actuel des templates ?
Dans certains cas peut-être. Le choix d'une forme de polymorphisme ou de l'autre devrait avant tout dépendre de critères de design et de performance. L'orienté-objet dynamique total (pex SmallTalk) permet de tout faire, mais a des coût excessifs en terme de performance. (C'est pourquoi, en Java, int/etc ne sont pas des objets). D'ou la puissance d'un polymorphisme traduit en phase de compilation (= programmation générique).
Le critère de performance, je l'oublie car dans la plupart des applis C++ (et surtout dans toutes celles que je connais) le goulot d'étranglement ne vient pas du polymorphisme dynamique.
Les "critères de design", c'est quoi ?
Le fait que la programmation générique devienne plus accessible pourrait permettre un choix plus libre entre ces deux niveaux de polymorphisme.
Comment ?
|> Je pense simplement que le C++ est un language complexe car il |> intègre nombre de |> concepts et de paradigmes de programmation. Ceci le rend |> puissant, mais aussi complexe et plus difficile à aborder. | |Ok. Donc en rajoutant de nouvelles notions qui simplifient une |certaine approche du développement, on complexifie la mise en |oeuvre d'une utilisation de C++.
Exactement. Une meilleure intégration d'autres paradigmes (p.ex. programmation fonctionnelle, introspection, etc) est également envisagée en C++. Il serait judicieux de trouver une approche et une syntaxe unifiée pour intégrer tous ces paradigmes (et qui soit un peu moins barbare que les templates actuels...).
Ok pour tout ça mais en pratique comment on fait pour ne pas complexifier la mise en oeuvre du langage ? Aujourd'hui c'est plutôt simple car les templates sont en fait relativement peu utilisés.
Gabriel Dos Reis
Olivier Azeau writes:
| Jean-Marc Bourguet wrote: | > Gabriel Dos Reis writes: | > | >>Jean-Marc Bourguet writes: | >> | >>[...] | >> | >>| Ma perception est que la mode est en train de s'etendre au dela des | >>| news et des cercles "inities", mais je peux me tromper. | >> | >>oui, malheureusement sans voir le fond de l'histoire :-( | > Je crois que plus que de capacites nouvelles en C++, ce dont certains | > manquent est une connaissance d'autres langages (et Java et C# ne | > comptent pas). | | Mais là j'ai l'impression que le problème est énoncé à l'envers. | | Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie | Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette | galaxie. | Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
| Jean-Marc Bourguet wrote:
| > Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| >
| >>Jean-Marc Bourguet <jm@bourguet.org> writes:
| >>
| >>[...]
| >>
| >>| Ma perception est que la mode est en train de s'etendre au dela des
| >>| news et des cercles "inities", mais je peux me tromper.
| >>
| >>oui, malheureusement sans voir le fond de l'histoire :-(
| > Je crois que plus que de capacites nouvelles en C++, ce dont certains
| > manquent est une connaissance d'autres langages (et Java et C# ne
| > comptent pas).
|
| Mais là j'ai l'impression que le problème est énoncé à l'envers.
|
| Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie
| Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette
| galaxie.
| Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
| Jean-Marc Bourguet wrote: | > Gabriel Dos Reis writes: | > | >>Jean-Marc Bourguet writes: | >> | >>[...] | >> | >>| Ma perception est que la mode est en train de s'etendre au dela des | >>| news et des cercles "inities", mais je peux me tromper. | >> | >>oui, malheureusement sans voir le fond de l'histoire :-( | > Je crois que plus que de capacites nouvelles en C++, ce dont certains | > manquent est une connaissance d'autres langages (et Java et C# ne | > comptent pas). | | Mais là j'ai l'impression que le problème est énoncé à l'envers. | | Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie | Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette | galaxie. | Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Je ne suis pas certain de te suivre.
-- Gaby
Gabriel Dos Reis
Olivier Azeau writes:
[...]
| Le critère de performance, je l'oublie car dans la plupart des applis | C++ (et surtout dans toutes celles que je connais) le goulot | d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
J'ai vu de très près un projet européen où l'un des goulots d'étranglement était précisément la virtualité à toutes les sauces : PoSSo. Ce n'est qu'un exemple mais, cela n'était du tout isolé un certain nombre de milieux. Va causer par exemple à ceux qui font du calcul numérique intensif.
| Le critère de performance, je l'oublie car dans la plupart des applis
| C++ (et surtout dans toutes celles que je connais) le goulot
| d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
J'ai vu de très près un projet européen où l'un des goulots
d'étranglement était précisément la virtualité à toutes les sauces :
PoSSo. Ce n'est qu'un exemple mais, cela n'était du tout isolé un
certain nombre de milieux.
Va causer par exemple à ceux qui font du calcul numérique intensif.
| Le critère de performance, je l'oublie car dans la plupart des applis | C++ (et surtout dans toutes celles que je connais) le goulot | d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
J'ai vu de très près un projet européen où l'un des goulots d'étranglement était précisément la virtualité à toutes les sauces : PoSSo. Ce n'est qu'un exemple mais, cela n'était du tout isolé un certain nombre de milieux. Va causer par exemple à ceux qui font du calcul numérique intensif.
-- Gaby
Olivier Azeau
Gabriel Dos Reis wrote:
Olivier Azeau writes:
[...]
| Le critère de performance, je l'oublie car dans la plupart des applis | C++ (et surtout dans toutes celles que je connais) le goulot | d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
Et cette réponse en dit autant à ton sujet ;-)
J'ai vu de très près un projet européen où l'un des goulots d'étranglement était précisément la virtualité à toutes les sauces : PoSSo. Ce n'est qu'un exemple mais, cela n'était du tout isolé un certain nombre de milieux. Va causer par exemple à ceux qui font du calcul numérique intensif.
Après un rapide Google, je vois un PoSSo "Polynomial System Solving" donc à ranger dans le même catégorie "calcul numérique intensif" (dont je ne connais effectivement aucun exemple "de près")
Dans les applis que je connais, les bottlenecks il faut les chercher dans les allocations dans le tas, les copies de données, le threading model, les accès réseau, les affichages graphiques, ....
| Le critère de performance, je l'oublie car dans la plupart des applis
| C++ (et surtout dans toutes celles que je connais) le goulot
| d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
Et cette réponse en dit autant à ton sujet ;-)
J'ai vu de très près un projet européen où l'un des goulots
d'étranglement était précisément la virtualité à toutes les sauces :
PoSSo. Ce n'est qu'un exemple mais, cela n'était du tout isolé un
certain nombre de milieux.
Va causer par exemple à ceux qui font du calcul numérique intensif.
Après un rapide Google, je vois un PoSSo "Polynomial System Solving"
donc à ranger dans le même catégorie "calcul numérique intensif" (dont
je ne connais effectivement aucun exemple "de près")
Dans les applis que je connais, les bottlenecks il faut les chercher
dans les allocations dans le tas, les copies de données, le threading
model, les accès réseau, les affichages graphiques, ....
| Le critère de performance, je l'oublie car dans la plupart des applis | C++ (et surtout dans toutes celles que je connais) le goulot | d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
Et cette réponse en dit autant à ton sujet ;-)
J'ai vu de très près un projet européen où l'un des goulots d'étranglement était précisément la virtualité à toutes les sauces : PoSSo. Ce n'est qu'un exemple mais, cela n'était du tout isolé un certain nombre de milieux. Va causer par exemple à ceux qui font du calcul numérique intensif.
Après un rapide Google, je vois un PoSSo "Polynomial System Solving" donc à ranger dans le même catégorie "calcul numérique intensif" (dont je ne connais effectivement aucun exemple "de près")
Dans les applis que je connais, les bottlenecks il faut les chercher dans les allocations dans le tas, les copies de données, le threading model, les accès réseau, les affichages graphiques, ....
Olivier Azeau
Gabriel Dos Reis wrote:
Olivier Azeau writes:
| Jean-Marc Bourguet wrote: | > Gabriel Dos Reis writes: | > | >>Jean-Marc Bourguet writes: | >> | >>[...] | >> | >>| Ma perception est que la mode est en train de s'etendre au dela des | >>| news et des cercles "inities", mais je peux me tromper. | >> | >>oui, malheureusement sans voir le fond de l'histoire :-( | > Je crois que plus que de capacites nouvelles en C++, ce dont certains | > manquent est une connaissance d'autres langages (et Java et C# ne | > comptent pas). | | Mais là j'ai l'impression que le problème est énoncé à l'envers. | | Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie | Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette | galaxie. | Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Je ne suis pas certain de te suivre.
En reprenant l'analogie du passage de C à C++ (qui m'a l'air de bien correspondre), le C faisait partie d'un certain contexte d'utilisateurs-développeurs qui était bien plus proche de Pascal ou Basic que des langages objets de l'époque. Le C++ a changé ce contexte (aux forceps).
Tout ce que je veux dire c'est que le C++ est aujourd'hui, dans une grande majorité d'utilisations, dans un certain contexte et que les évolutions présentées visent à l'emmener "ailleurs", ce qui représente un coût "social" important.
| Jean-Marc Bourguet wrote:
| > Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| >
| >>Jean-Marc Bourguet <jm@bourguet.org> writes:
| >>
| >>[...]
| >>
| >>| Ma perception est que la mode est en train de s'etendre au dela des
| >>| news et des cercles "inities", mais je peux me tromper.
| >>
| >>oui, malheureusement sans voir le fond de l'histoire :-(
| > Je crois que plus que de capacites nouvelles en C++, ce dont certains
| > manquent est une connaissance d'autres langages (et Java et C# ne
| > comptent pas).
|
| Mais là j'ai l'impression que le problème est énoncé à l'envers.
|
| Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie
| Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette
| galaxie.
| Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Je ne suis pas certain de te suivre.
En reprenant l'analogie du passage de C à C++ (qui m'a l'air de bien
correspondre), le C faisait partie d'un certain contexte
d'utilisateurs-développeurs qui était bien plus proche de Pascal ou
Basic que des langages objets de l'époque. Le C++ a changé ce contexte
(aux forceps).
Tout ce que je veux dire c'est que le C++ est aujourd'hui, dans une
grande majorité d'utilisations, dans un certain contexte et que les
évolutions présentées visent à l'emmener "ailleurs", ce qui représente
un coût "social" important.
| Jean-Marc Bourguet wrote: | > Gabriel Dos Reis writes: | > | >>Jean-Marc Bourguet writes: | >> | >>[...] | >> | >>| Ma perception est que la mode est en train de s'etendre au dela des | >>| news et des cercles "inities", mais je peux me tromper. | >> | >>oui, malheureusement sans voir le fond de l'histoire :-( | > Je crois que plus que de capacites nouvelles en C++, ce dont certains | > manquent est une connaissance d'autres langages (et Java et C# ne | > comptent pas). | | Mais là j'ai l'impression que le problème est énoncé à l'envers. | | Nombre de développeurs ont aujourd'hui à naviguer dans une galaxie | Java, C#, VB, Php, etc. et le C++ fait factuellement partie de cette | galaxie. | Pas par ce qu'il pourrait être mais parce que c'est de là qu'il vient.
Je ne suis pas certain de te suivre.
En reprenant l'analogie du passage de C à C++ (qui m'a l'air de bien correspondre), le C faisait partie d'un certain contexte d'utilisateurs-développeurs qui était bien plus proche de Pascal ou Basic que des langages objets de l'époque. Le C++ a changé ce contexte (aux forceps).
Tout ce que je veux dire c'est que le C++ est aujourd'hui, dans une grande majorité d'utilisations, dans un certain contexte et que les évolutions présentées visent à l'emmener "ailleurs", ce qui représente un coût "social" important.
Ivan Vecerina
"Olivier Azeau" wrote in message news:1ldMd.19835$
Le code de 'Document' est intégralement dupliqué. Ceci peut apporter un gain de performance à l'exécution en au coût d'une quantité de code supplémentaire. Un gain aussi si seulement un des deux types de documents doit être compilé dans une application.
Et alors ?
Réfléchir...
|Mais justement, est-ce que la problematique du choix de l'approche |n'est pas principalement due aux difficultés de mise en oeuvre du |"polymorphisme de compilation" dans l'état actuel des templates ?
Dans certains cas peut-être. Le choix d'une forme de polymorphisme ou de l'autre devrait avant tout dépendre de critères de design et de performance. L'orienté-objet dynamique total (pex SmallTalk) permet de tout faire, mais a des coût excessifs en terme de performance. (C'est pourquoi, en Java, int/etc ne sont pas des objets). D'ou la puissance d'un polymorphisme traduit en phase de compilation (= programmation générique).
Le critère de performance, je l'oublie car dans la plupart des applis C++ (et surtout dans toutes celles que je connais) le goulot d'étranglement ne vient pas du polymorphisme dynamique.
Les "critères de design", c'est quoi ?
Par exemple, au vol:
En faveur du polymorphisme de substitution (run-time polymorphism): - besoin de changer le comportement d'une instance en cours d'exécution (p.ex. avec Strategy, Bridge ou Template Method), p.ex. pour afficher un document sur une imprimante post-script. - nombre exponentiel de combinaisons possible, avec croissance linéaire de la taille du code (p.ex. multiples types de documents utilisant multiples variantes de mode d'affichage). - accès dynamique à de nouvelles variantes (p.ex. modules d'extension intégrés sans recompilation, et web services etc).
En faveur du polymorphisme paramétrique: - Validation du code à la compilation (type safety, etc). - Efficacité du code généré (pas de 'dispatching' dynamique). - Compacité du code - Possibilité de paramétrer plus en profondeur le comportement (p.ex. quels types utiliser pour des résultats intermédiaires). - Possibilité que de nombreux utilisateurs utilisent une même librairie dans des contextes distincts sans être encombrés (taille code, points de customisation) par les besoins des autres.
Comme déjà indiqué, il serait possible de faire du tout-dynamique (chaque valeur est un objet recevant des messages), mais en pratique ce n'est pas acceptable. [et pour info, Java est loin d'être du tout-dynamique.].
Le fait que la programmation générique devienne plus accessible pourrait permettre un choix plus libre entre ces deux niveaux de polymorphisme.
Comment ?
Aujourd'hui, parce qu'ils ne savent pas comment exploiter les templates en C++, bien des développeurs dupliquent ou réécrivent souvent du code, ou encore utilisent du polymorphisme paramétrique dans des circonstances inapropriées. Permettre à chacun d'expoiter la paramétrisation serait un pas en avant. Permettre encore de passer plus facilement d'une approche à l'autre serait bénéfique également.
|> Je pense simplement que le C++ est un language complexe car il |> intègre nombre de |> concepts et de paradigmes de programmation. Ceci le rend |> puissant, mais aussi complexe et plus difficile à aborder. | |Ok. Donc en rajoutant de nouvelles notions qui simplifient une |certaine approche du développement, on complexifie la mise en |oeuvre d'une utilisation de C++.
Exactement. Une meilleure intégration d'autres paradigmes (p.ex. programmation fonctionnelle, introspection, etc) est également envisagée en C++. Il serait judicieux de trouver une approche et une syntaxe unifiée pour intégrer tous ces paradigmes (et qui soit un peu moins barbare que les templates actuels...).
Ok pour tout ça mais en pratique comment on fait pour ne pas complexifier la mise en oeuvre du langage ? Aujourd'hui c'est plutôt simple car les templates sont en fait relativement peu utilisés.
??? Il me semble qu'à ce jour les STL de la librairie standard sont utilisés de plus en plus intensément. Et qui n'utilise pas des 'smart pointers' en C++ (également des templates) rate sérieusement quelque chose en terme de qualité/maintenance/etc du code.
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
"Olivier Azeau" <read.my.name.and.email.to.firstname@lastname.com> wrote in
message news:1ldMd.19835$Of5.13214@nntpserver.swip.net...
Le code de 'Document' est intégralement dupliqué.
Ceci peut apporter un gain de performance à l'exécution
en au coût d'une quantité de code supplémentaire. Un gain
aussi si seulement un des deux types de documents doit
être compilé dans une application.
Et alors ?
Réfléchir...
|Mais justement, est-ce que la problematique du choix de l'approche
|n'est pas principalement due aux difficultés de mise en oeuvre du
|"polymorphisme de compilation" dans l'état actuel des templates ?
Dans certains cas peut-être. Le choix d'une forme de polymorphisme
ou de l'autre devrait avant tout dépendre de critères de design
et de performance. L'orienté-objet dynamique total (pex SmallTalk)
permet de tout faire, mais a des coût excessifs en terme de
performance. (C'est pourquoi, en Java, int/etc ne sont pas
des objets). D'ou la puissance d'un polymorphisme traduit
en phase de compilation (= programmation générique).
Le critère de performance, je l'oublie car dans la plupart des applis C++
(et surtout dans toutes celles que je connais) le goulot d'étranglement ne
vient pas du polymorphisme dynamique.
Les "critères de design", c'est quoi ?
Par exemple, au vol:
En faveur du polymorphisme de substitution (run-time polymorphism):
- besoin de changer le comportement d'une instance en cours
d'exécution (p.ex. avec Strategy, Bridge ou Template Method),
p.ex. pour afficher un document sur une imprimante post-script.
- nombre exponentiel de combinaisons possible, avec croissance
linéaire de la taille du code (p.ex. multiples types de documents
utilisant multiples variantes de mode d'affichage).
- accès dynamique à de nouvelles variantes (p.ex. modules
d'extension intégrés sans recompilation, et web services etc).
En faveur du polymorphisme paramétrique:
- Validation du code à la compilation (type safety, etc).
- Efficacité du code généré (pas de 'dispatching' dynamique).
- Compacité du code
- Possibilité de paramétrer plus en profondeur le comportement
(p.ex. quels types utiliser pour des résultats intermédiaires).
- Possibilité que de nombreux utilisateurs utilisent une même
librairie dans des contextes distincts sans être encombrés
(taille code, points de customisation) par les besoins des
autres.
Comme déjà indiqué, il serait possible de faire du tout-dynamique
(chaque valeur est un objet recevant des messages), mais en
pratique ce n'est pas acceptable. [et pour info, Java est
loin d'être du tout-dynamique.].
Le fait que la programmation générique devienne plus accessible
pourrait permettre un choix plus libre entre ces deux niveaux
de polymorphisme.
Comment ?
Aujourd'hui, parce qu'ils ne savent pas comment exploiter les
templates en C++, bien des développeurs dupliquent ou réécrivent
souvent du code, ou encore utilisent du polymorphisme paramétrique
dans des circonstances inapropriées.
Permettre à chacun d'expoiter la paramétrisation serait un pas
en avant. Permettre encore de passer plus facilement d'une approche
à l'autre serait bénéfique également.
|> Je pense simplement que le C++ est un language complexe car il
|> intègre nombre de
|> concepts et de paradigmes de programmation. Ceci le rend
|> puissant, mais aussi complexe et plus difficile à aborder.
|
|Ok. Donc en rajoutant de nouvelles notions qui simplifient une
|certaine approche du développement, on complexifie la mise en
|oeuvre d'une utilisation de C++.
Exactement.
Une meilleure intégration d'autres paradigmes (p.ex.
programmation fonctionnelle, introspection, etc) est
également envisagée en C++. Il serait judicieux de
trouver une approche et une syntaxe unifiée pour
intégrer tous ces paradigmes (et qui soit un peu
moins barbare que les templates actuels...).
Ok pour tout ça mais en pratique comment on fait pour ne pas complexifier
la mise en oeuvre du langage ?
Aujourd'hui c'est plutôt simple car les templates sont en fait
relativement peu utilisés.
??? Il me semble qu'à ce jour les STL de la librairie standard
sont utilisés de plus en plus intensément. Et qui n'utilise
pas des 'smart pointers' en C++ (également des templates) rate
sérieusement quelque chose en terme de qualité/maintenance/etc
du code.
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
"Olivier Azeau" wrote in message news:1ldMd.19835$
Le code de 'Document' est intégralement dupliqué. Ceci peut apporter un gain de performance à l'exécution en au coût d'une quantité de code supplémentaire. Un gain aussi si seulement un des deux types de documents doit être compilé dans une application.
Et alors ?
Réfléchir...
|Mais justement, est-ce que la problematique du choix de l'approche |n'est pas principalement due aux difficultés de mise en oeuvre du |"polymorphisme de compilation" dans l'état actuel des templates ?
Dans certains cas peut-être. Le choix d'une forme de polymorphisme ou de l'autre devrait avant tout dépendre de critères de design et de performance. L'orienté-objet dynamique total (pex SmallTalk) permet de tout faire, mais a des coût excessifs en terme de performance. (C'est pourquoi, en Java, int/etc ne sont pas des objets). D'ou la puissance d'un polymorphisme traduit en phase de compilation (= programmation générique).
Le critère de performance, je l'oublie car dans la plupart des applis C++ (et surtout dans toutes celles que je connais) le goulot d'étranglement ne vient pas du polymorphisme dynamique.
Les "critères de design", c'est quoi ?
Par exemple, au vol:
En faveur du polymorphisme de substitution (run-time polymorphism): - besoin de changer le comportement d'une instance en cours d'exécution (p.ex. avec Strategy, Bridge ou Template Method), p.ex. pour afficher un document sur une imprimante post-script. - nombre exponentiel de combinaisons possible, avec croissance linéaire de la taille du code (p.ex. multiples types de documents utilisant multiples variantes de mode d'affichage). - accès dynamique à de nouvelles variantes (p.ex. modules d'extension intégrés sans recompilation, et web services etc).
En faveur du polymorphisme paramétrique: - Validation du code à la compilation (type safety, etc). - Efficacité du code généré (pas de 'dispatching' dynamique). - Compacité du code - Possibilité de paramétrer plus en profondeur le comportement (p.ex. quels types utiliser pour des résultats intermédiaires). - Possibilité que de nombreux utilisateurs utilisent une même librairie dans des contextes distincts sans être encombrés (taille code, points de customisation) par les besoins des autres.
Comme déjà indiqué, il serait possible de faire du tout-dynamique (chaque valeur est un objet recevant des messages), mais en pratique ce n'est pas acceptable. [et pour info, Java est loin d'être du tout-dynamique.].
Le fait que la programmation générique devienne plus accessible pourrait permettre un choix plus libre entre ces deux niveaux de polymorphisme.
Comment ?
Aujourd'hui, parce qu'ils ne savent pas comment exploiter les templates en C++, bien des développeurs dupliquent ou réécrivent souvent du code, ou encore utilisent du polymorphisme paramétrique dans des circonstances inapropriées. Permettre à chacun d'expoiter la paramétrisation serait un pas en avant. Permettre encore de passer plus facilement d'une approche à l'autre serait bénéfique également.
|> Je pense simplement que le C++ est un language complexe car il |> intègre nombre de |> concepts et de paradigmes de programmation. Ceci le rend |> puissant, mais aussi complexe et plus difficile à aborder. | |Ok. Donc en rajoutant de nouvelles notions qui simplifient une |certaine approche du développement, on complexifie la mise en |oeuvre d'une utilisation de C++.
Exactement. Une meilleure intégration d'autres paradigmes (p.ex. programmation fonctionnelle, introspection, etc) est également envisagée en C++. Il serait judicieux de trouver une approche et une syntaxe unifiée pour intégrer tous ces paradigmes (et qui soit un peu moins barbare que les templates actuels...).
Ok pour tout ça mais en pratique comment on fait pour ne pas complexifier la mise en oeuvre du langage ? Aujourd'hui c'est plutôt simple car les templates sont en fait relativement peu utilisés.
??? Il me semble qu'à ce jour les STL de la librairie standard sont utilisés de plus en plus intensément. Et qui n'utilise pas des 'smart pointers' en C++ (également des templates) rate sérieusement quelque chose en terme de qualité/maintenance/etc du code.
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Ivan Vecerina
"Olivier Azeau" wrote in message news:FRjMd.19871$
Gabriel Dos Reis wrote:
Olivier Azeau writes: | Le critère de performance, je l'oublie car dans la plupart des applis | C++ (et surtout dans toutes celles que je connais) le goulot | d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
Et cette réponse en dit autant à ton sujet ;-)
AMHA Gaby ne manque jamais de courtoisie envers ceux qui cherchent à apporter des réponses à ses questions.
J'ai vu de très près un projet européen où l'un des goulots d'étranglement était précisément la virtualité à toutes les sauces : ....
Dans les applis que je connais, les bottlenecks il faut les chercher dans les allocations dans le tas, -> paramétrisation des collections génériques par un allocator
pour permettre des optimisation.
les copies de données, -> usage de "policy classes" et de "smart pointers" pour optimiser
ou éviter les copies lorsque c'est possible.
le threading model, -> possibilité de simplifier et d'automatiser le verrouillage
d'objets (templates, RAII, surcharge d'opérateur ->), possibilité de paramétriser le mode de synchronisation (pour optimisation).
les accès réseau, -> Une paramétrisation peut permettre d'optimiser le format de
sérialisation (plus compacte, conversions plus rapides).
les affichages graphiques, -> A partir du même code source, la paramétrisation permet
entre autres de générer du code optimisé pour divers formats d'affichage et profondeurs de pixels, etc.
... etc
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
"Olivier Azeau" <read.my.name.and.email.to.firstname@lastname.com> wrote in
message news:FRjMd.19871$Of5.13294@nntpserver.swip.net...
Gabriel Dos Reis wrote:
Olivier Azeau <read.my.name.and.email.to.firstname@lastname.com> writes:
| Le critère de performance, je l'oublie car dans la plupart des applis
| C++ (et surtout dans toutes celles que je connais) le goulot
| d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
Et cette réponse en dit autant à ton sujet ;-)
AMHA Gaby ne manque jamais de courtoisie envers ceux qui cherchent
à apporter des réponses à ses questions.
J'ai vu de très près un projet européen où l'un des goulots
d'étranglement était précisément la virtualité à toutes les sauces :
....
Dans les applis que je connais, les bottlenecks il faut les chercher dans
les allocations dans le tas,
-> paramétrisation des collections génériques par un allocator
pour permettre des optimisation.
les copies de données,
-> usage de "policy classes" et de "smart pointers" pour optimiser
ou éviter les copies lorsque c'est possible.
le threading model,
-> possibilité de simplifier et d'automatiser le verrouillage
d'objets (templates, RAII, surcharge d'opérateur ->), possibilité
de paramétriser le mode de synchronisation (pour optimisation).
les accès réseau,
-> Une paramétrisation peut permettre d'optimiser le format de
sérialisation (plus compacte, conversions plus rapides).
les affichages graphiques,
-> A partir du même code source, la paramétrisation permet
entre autres de générer du code optimisé pour divers formats
d'affichage et profondeurs de pixels, etc.
...
etc
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
"Olivier Azeau" wrote in message news:FRjMd.19871$
Gabriel Dos Reis wrote:
Olivier Azeau writes: | Le critère de performance, je l'oublie car dans la plupart des applis | C++ (et surtout dans toutes celles que je connais) le goulot | d'étranglement ne vient pas du polymorphisme dynamique.
cela en dit beaucoup sur les programmes que tu n'as pas vus ;-/
Et cette réponse en dit autant à ton sujet ;-)
AMHA Gaby ne manque jamais de courtoisie envers ceux qui cherchent à apporter des réponses à ses questions.
J'ai vu de très près un projet européen où l'un des goulots d'étranglement était précisément la virtualité à toutes les sauces : ....
Dans les applis que je connais, les bottlenecks il faut les chercher dans les allocations dans le tas, -> paramétrisation des collections génériques par un allocator
pour permettre des optimisation.
les copies de données, -> usage de "policy classes" et de "smart pointers" pour optimiser
ou éviter les copies lorsque c'est possible.
le threading model, -> possibilité de simplifier et d'automatiser le verrouillage
d'objets (templates, RAII, surcharge d'opérateur ->), possibilité de paramétriser le mode de synchronisation (pour optimisation).
les accès réseau, -> Une paramétrisation peut permettre d'optimiser le format de
sérialisation (plus compacte, conversions plus rapides).
les affichages graphiques, -> A partir du même code source, la paramétrisation permet
entre autres de générer du code optimisé pour divers formats d'affichage et profondeurs de pixels, etc.
... etc
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
