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...
"Alain Naigeon" wrote in message news:4204038c$0$602$
"Ivan Vecerina" a écrit dans le message news: cu0s5d$jn2$
On ne perd certainement pas en puissance et en flexibilité en faisant du tout-object et tout-dynamique. Cependant, même dans des applications banales, ceci a un coût souvent rédhibitoire.
C'est marrant, quand il s'est agi de passer de C à C++, on affirmait le contraire à ceux qui émettaient des doutes (ou qui ne voyaient pas ce qu'on gagnait en temps de mise au point et en sécurité)
L'orienté-objet introduit par le C++ n'a rien à voir avec le dynamisme quasi-total offert par un language comme SmallTalk.
Oui et non. La notion de la résolution à l'execution y est. Mais comme Eiffel, il ne rénonce pas à la vérification statique des types, et je crois que Stroustrup a été influencé par Meyers pour certaines choses. (En revanche, je ne suis pas sûr qu'il n'a pas introduit l'héritage avant de connaître l'oeuvre de Meyers. Il faudrait lui démander.)
Pour info, voir par exemple: http://www.objs.com/x3h7/smalltalk.htm L' Objective-C, sur lequel NeXT fut basé, avait intégré ce dynamisme au C: métaclasses, possibilité de filtrer ou déléguer les messages reçus par un objet, ou de modifier et d'étendre dynamiquement les méthodes d'une classe.
L'Objective-C, d'après le peu que j'ai vu, c'est une expérience curieuse. Un peu deux langages en un -- Smalltalk et C. J'aurais bien aimé m'en servir pour un projet, ne serait-ce que pour voir ce que ça donne. (Mais j'ai mes doutes. C'est trivial de faire deux langages en un ; faire qu'ils travaillent bien ensemble, c'est une autre histoire.)
Le C++ a intégré la programmation objet au C, mais sous une forme "light" et peu couteuse en performance.
C'était, je crois, un critère de Stroustrup. Mais il ne faut pas oublier que le vrai intérêt de C++, par rapport à Smalltalk, c'est la vérification statique des types. Moi, en tout cas, je préfère toujours l'erreur à la compilation à l'erreur lors de l'execution.
Fonctions virtuelles pour le polymorphisme, et un rudiment d'embryon d'introspection avec typeinfo -- pas comparable à l'OO dynamique pur du SmallTalk.
L'introspection est venu très tardivement, bien après que le C++ s'est imposé. Quant à la reste... Je doute que la comparaison avec Smalltalk ait jamais été significative. Le concurrent, pendant longtemps, a été Eiffel.
C'est un des cas où la robustesse et la performance vont ensemble.
Aujourd'hui encore, Java, CLR/.NET, etc, sont loin d'aller aussi loin dans le dynamisme et l'orienté objet.
Ce n'est pas l'avis de la plupart du monde. J'entends souvent que le Java, c'est un langage OO pure. (Ce qui est une bêtise, pour plus d'une raison, mais on l'entend quand même.)
Chose qui est certain, c'est que l'argument de C++ aujourd'hui n'est plus la vitesse pûre -- on peut arriver à la même vitesse, sinon plus, avec Java. L'argumentation du C++ aujourd'hui, à mon avis, c'est la robustesse. Et son seul concurrent, c'est Ada 95 (à moins qu'on considère des langages vraiment mineur, comme Modula 3).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ivan Vecerina wrote:
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:4204038c$0$602$636a15ce@news.free.fr...
"Ivan Vecerina" <INVALID_use_webform_instead@vecerina.com> a
écrit dans le message news: cu0s5d$jn2$1@news.hispeed.ch...
On ne perd certainement pas en puissance et en flexibilité
en faisant du tout-object et tout-dynamique. Cependant,
même dans des applications banales, ceci a un coût souvent
rédhibitoire.
C'est marrant, quand il s'est agi de passer de C à C++, on
affirmait le contraire à ceux qui émettaient des doutes (ou
qui ne voyaient pas ce qu'on gagnait en temps de mise au
point et en sécurité)
L'orienté-objet introduit par le C++ n'a rien à voir avec le
dynamisme quasi-total offert par un language comme SmallTalk.
Oui et non. La notion de la résolution à l'execution y est. Mais
comme Eiffel, il ne rénonce pas à la vérification statique des
types, et je crois que Stroustrup a été influencé par Meyers
pour certaines choses. (En revanche, je ne suis pas sûr qu'il
n'a pas introduit l'héritage avant de connaître l'oeuvre de
Meyers. Il faudrait lui démander.)
Pour info, voir par exemple:
http://www.objs.com/x3h7/smalltalk.htm L' Objective-C, sur
lequel NeXT fut basé, avait intégré ce dynamisme au C:
métaclasses, possibilité de filtrer ou déléguer les messages
reçus par un objet, ou de modifier et d'étendre dynamiquement
les méthodes d'une classe.
L'Objective-C, d'après le peu que j'ai vu, c'est une expérience
curieuse. Un peu deux langages en un -- Smalltalk et C. J'aurais
bien aimé m'en servir pour un projet, ne serait-ce que pour voir
ce que ça donne. (Mais j'ai mes doutes. C'est trivial de faire
deux langages en un ; faire qu'ils travaillent bien ensemble,
c'est une autre histoire.)
Le C++ a intégré la programmation objet au C, mais sous une
forme "light" et peu couteuse en performance.
C'était, je crois, un critère de Stroustrup. Mais il ne faut pas
oublier que le vrai intérêt de C++, par rapport à Smalltalk,
c'est la vérification statique des types. Moi, en tout cas, je
préfère toujours l'erreur à la compilation à l'erreur lors de
l'execution.
Fonctions virtuelles pour le polymorphisme, et un rudiment
d'embryon d'introspection avec typeinfo -- pas comparable à
l'OO dynamique pur du SmallTalk.
L'introspection est venu très tardivement, bien après que le C++
s'est imposé. Quant à la reste... Je doute que la comparaison
avec Smalltalk ait jamais été significative. Le concurrent,
pendant longtemps, a été Eiffel.
C'est un des cas où la robustesse et la performance vont
ensemble.
Aujourd'hui encore, Java, CLR/.NET, etc, sont loin d'aller
aussi loin dans le dynamisme et l'orienté objet.
Ce n'est pas l'avis de la plupart du monde. J'entends souvent
que le Java, c'est un langage OO pure. (Ce qui est une bêtise,
pour plus d'une raison, mais on l'entend quand même.)
Chose qui est certain, c'est que l'argument de C++ aujourd'hui
n'est plus la vitesse pûre -- on peut arriver à la même vitesse,
sinon plus, avec Java. L'argumentation du C++ aujourd'hui, à mon
avis, c'est la robustesse. Et son seul concurrent, c'est Ada 95
(à moins qu'on considère des langages vraiment mineur, comme
Modula 3).
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Alain Naigeon" wrote in message news:4204038c$0$602$
"Ivan Vecerina" a écrit dans le message news: cu0s5d$jn2$
On ne perd certainement pas en puissance et en flexibilité en faisant du tout-object et tout-dynamique. Cependant, même dans des applications banales, ceci a un coût souvent rédhibitoire.
C'est marrant, quand il s'est agi de passer de C à C++, on affirmait le contraire à ceux qui émettaient des doutes (ou qui ne voyaient pas ce qu'on gagnait en temps de mise au point et en sécurité)
L'orienté-objet introduit par le C++ n'a rien à voir avec le dynamisme quasi-total offert par un language comme SmallTalk.
Oui et non. La notion de la résolution à l'execution y est. Mais comme Eiffel, il ne rénonce pas à la vérification statique des types, et je crois que Stroustrup a été influencé par Meyers pour certaines choses. (En revanche, je ne suis pas sûr qu'il n'a pas introduit l'héritage avant de connaître l'oeuvre de Meyers. Il faudrait lui démander.)
Pour info, voir par exemple: http://www.objs.com/x3h7/smalltalk.htm L' Objective-C, sur lequel NeXT fut basé, avait intégré ce dynamisme au C: métaclasses, possibilité de filtrer ou déléguer les messages reçus par un objet, ou de modifier et d'étendre dynamiquement les méthodes d'une classe.
L'Objective-C, d'après le peu que j'ai vu, c'est une expérience curieuse. Un peu deux langages en un -- Smalltalk et C. J'aurais bien aimé m'en servir pour un projet, ne serait-ce que pour voir ce que ça donne. (Mais j'ai mes doutes. C'est trivial de faire deux langages en un ; faire qu'ils travaillent bien ensemble, c'est une autre histoire.)
Le C++ a intégré la programmation objet au C, mais sous une forme "light" et peu couteuse en performance.
C'était, je crois, un critère de Stroustrup. Mais il ne faut pas oublier que le vrai intérêt de C++, par rapport à Smalltalk, c'est la vérification statique des types. Moi, en tout cas, je préfère toujours l'erreur à la compilation à l'erreur lors de l'execution.
Fonctions virtuelles pour le polymorphisme, et un rudiment d'embryon d'introspection avec typeinfo -- pas comparable à l'OO dynamique pur du SmallTalk.
L'introspection est venu très tardivement, bien après que le C++ s'est imposé. Quant à la reste... Je doute que la comparaison avec Smalltalk ait jamais été significative. Le concurrent, pendant longtemps, a été Eiffel.
C'est un des cas où la robustesse et la performance vont ensemble.
Aujourd'hui encore, Java, CLR/.NET, etc, sont loin d'aller aussi loin dans le dynamisme et l'orienté objet.
Ce n'est pas l'avis de la plupart du monde. J'entends souvent que le Java, c'est un langage OO pure. (Ce qui est une bêtise, pour plus d'une raison, mais on l'entend quand même.)
Chose qui est certain, c'est que l'argument de C++ aujourd'hui n'est plus la vitesse pûre -- on peut arriver à la même vitesse, sinon plus, avec Java. L'argumentation du C++ aujourd'hui, à mon avis, c'est la robustesse. Et son seul concurrent, c'est Ada 95 (à moins qu'on considère des langages vraiment mineur, comme Modula 3).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Olivier Azeau wrote:
Ivan Vecerina wrote:
| wrote in message |news: |Quel rapport ? Quand les templates conviennent, on utilise |les templates. Quand l'héritage convient, on utilise |l'héritage. Les deux sont là pour une raison, et c'est même |plutôt rare que leurs champs d'applications se récouvrent.
On ne perd certainement pas en puissance et en flexibilité en faisant du tout-object et tout-dynamique. Cependant, même dans des applications banales, ceci a un coût souvent rédhibitoire.
Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un synonyme de "la plupart")
Pas forcement. Je mange souvent (plusieurs fois par jour, même), mais je ne passe pas la plupart de mon temps à manger.
J'ai croisé la route d'un certain nombre d'applis avec du C++ dedans qui, certes, ne sont probablement pas représentatives de quoi que ce soit et je n'ai jamais vu un tel coût rédhibitoire.
Le coût d'un dynamisme non-nécessaire est loin d'être negligeable. Le dynamisme ajoute à la complexité du code, et nuit à sa robustesse. Il a donc un coût non nul. Quand il apporte quelque chose de plus, on utilise. Quand il n'apporte rien, il vaut mieux s'en passer.
Ceci étant dit, personne ne fait du tout-dynamique pour le plaisir d'en faire : il arrive parfois à quelqu'un qui n'utilise jamais de templates de mettre autre chose que des pointeurs comme membres de ses classes.
J'entends souvent ça, mais je ne l'ai jamais vu. Il ne faut pas exagérer, quand même. La plupart des programmeurs ne sont pas des cons.
Mais enfin, dans les boîtes où j'ai travaillé, on imposait en général une conception avant, ce qui permettait à savoir quelle fonctions devaient être virtuelles, et quelles non. Je suis très contre l'idée qu'on déclare toute fonction virtuelle, parce qu'on ne sait jamais. Et non pour les raisons de performance ; une classe ne sert effectivement comme classe de base que si elle était conçue pour être une classe de base.
C'est pour pouvoir manipuler des données (relativement) brutes et pas tout-à-fait encapsulée derrière des objets et des messages que l'on doit se résoudre à avoir recours à d'autres formes de dispatching et de réutilisation de code.
C'est quoi ces données brutes ? Des grands jeux de données en mémoire ? ;-)
Le résultat, en C++, est effectivement que l'on a des champs d'application relativement distincts pour les templates et les fonctions virtuelles/héritages.
En l'état actuel, je vois surtout des champs sociologiques distincts : des connaisseurs++ qui font des templates et les autres.
En l'état actuel, je ne vois personne qui ne se sert pas des templates en C++. On a lutté assez avec <generic.h> pour apprendre la leçon. En revanche, j'en vois beaucoup qui limitent les templates à des choses simple, genre tableau. Mais j'en vois aussi beaucoup qui sont obligé à utiliser des compilateurs périmés. Or, je trouve très peu de clients près à payer pour qu'on écrive du code qui ne marcherait que si.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Olivier Azeau wrote:
Ivan Vecerina wrote:
|<kanze@gabi-soft.fr> wrote in message
|news:1107507856.068380.121410@l41g2000cwc.googlegroups.com...
|Quel rapport ? Quand les templates conviennent, on utilise
|les templates. Quand l'héritage convient, on utilise
|l'héritage. Les deux sont là pour une raison, et c'est même
|plutôt rare que leurs champs d'applications se récouvrent.
On ne perd certainement pas en puissance et en flexibilité
en faisant du tout-object et tout-dynamique. Cependant, même
dans des applications banales, ceci a un coût souvent
rédhibitoire.
Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un
synonyme de "la plupart")
Pas forcement. Je mange souvent (plusieurs fois par jour, même),
mais je ne passe pas la plupart de mon temps à manger.
J'ai croisé la route d'un certain nombre d'applis avec du C++
dedans qui, certes, ne sont probablement pas représentatives
de quoi que ce soit et je n'ai jamais vu un tel coût
rédhibitoire.
Le coût d'un dynamisme non-nécessaire est loin d'être
negligeable. Le dynamisme ajoute à la complexité du code, et
nuit à sa robustesse. Il a donc un coût non nul. Quand il
apporte quelque chose de plus, on utilise. Quand il n'apporte
rien, il vaut mieux s'en passer.
Ceci étant dit, personne ne fait du tout-dynamique pour le
plaisir d'en faire : il arrive parfois à quelqu'un qui
n'utilise jamais de templates de mettre autre chose que des
pointeurs comme membres de ses classes.
J'entends souvent ça, mais je ne l'ai jamais vu. Il ne faut pas
exagérer, quand même. La plupart des programmeurs ne sont pas
des cons.
Mais enfin, dans les boîtes où j'ai travaillé, on imposait en
général une conception avant, ce qui permettait à savoir quelle
fonctions devaient être virtuelles, et quelles non. Je suis très
contre l'idée qu'on déclare toute fonction virtuelle, parce
qu'on ne sait jamais. Et non pour les raisons de performance ;
une classe ne sert effectivement comme classe de base que si
elle était conçue pour être une classe de base.
C'est pour pouvoir manipuler des données (relativement)
brutes et pas tout-à-fait encapsulée derrière des objets et
des messages que l'on doit se résoudre à avoir recours à
d'autres formes de dispatching et de réutilisation de code.
C'est quoi ces données brutes ?
Des grands jeux de données en mémoire ? ;-)
Le résultat, en C++, est effectivement que l'on a des champs
d'application relativement distincts pour les templates et
les fonctions virtuelles/héritages.
En l'état actuel, je vois surtout des champs sociologiques
distincts : des connaisseurs++ qui font des templates et les
autres.
En l'état actuel, je ne vois personne qui ne se sert pas des
templates en C++. On a lutté assez avec <generic.h> pour
apprendre la leçon. En revanche, j'en vois beaucoup qui limitent
les templates à des choses simple, genre tableau. Mais j'en vois
aussi beaucoup qui sont obligé à utiliser des compilateurs
périmés. Or, je trouve très peu de clients près à payer pour
qu'on écrive du code qui ne marcherait que si.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| wrote in message |news: |Quel rapport ? Quand les templates conviennent, on utilise |les templates. Quand l'héritage convient, on utilise |l'héritage. Les deux sont là pour une raison, et c'est même |plutôt rare que leurs champs d'applications se récouvrent.
On ne perd certainement pas en puissance et en flexibilité en faisant du tout-object et tout-dynamique. Cependant, même dans des applications banales, ceci a un coût souvent rédhibitoire.
Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un synonyme de "la plupart")
Pas forcement. Je mange souvent (plusieurs fois par jour, même), mais je ne passe pas la plupart de mon temps à manger.
J'ai croisé la route d'un certain nombre d'applis avec du C++ dedans qui, certes, ne sont probablement pas représentatives de quoi que ce soit et je n'ai jamais vu un tel coût rédhibitoire.
Le coût d'un dynamisme non-nécessaire est loin d'être negligeable. Le dynamisme ajoute à la complexité du code, et nuit à sa robustesse. Il a donc un coût non nul. Quand il apporte quelque chose de plus, on utilise. Quand il n'apporte rien, il vaut mieux s'en passer.
Ceci étant dit, personne ne fait du tout-dynamique pour le plaisir d'en faire : il arrive parfois à quelqu'un qui n'utilise jamais de templates de mettre autre chose que des pointeurs comme membres de ses classes.
J'entends souvent ça, mais je ne l'ai jamais vu. Il ne faut pas exagérer, quand même. La plupart des programmeurs ne sont pas des cons.
Mais enfin, dans les boîtes où j'ai travaillé, on imposait en général une conception avant, ce qui permettait à savoir quelle fonctions devaient être virtuelles, et quelles non. Je suis très contre l'idée qu'on déclare toute fonction virtuelle, parce qu'on ne sait jamais. Et non pour les raisons de performance ; une classe ne sert effectivement comme classe de base que si elle était conçue pour être une classe de base.
C'est pour pouvoir manipuler des données (relativement) brutes et pas tout-à-fait encapsulée derrière des objets et des messages que l'on doit se résoudre à avoir recours à d'autres formes de dispatching et de réutilisation de code.
C'est quoi ces données brutes ? Des grands jeux de données en mémoire ? ;-)
Le résultat, en C++, est effectivement que l'on a des champs d'application relativement distincts pour les templates et les fonctions virtuelles/héritages.
En l'état actuel, je vois surtout des champs sociologiques distincts : des connaisseurs++ qui font des templates et les autres.
En l'état actuel, je ne vois personne qui ne se sert pas des templates en C++. On a lutté assez avec <generic.h> pour apprendre la leçon. En revanche, j'en vois beaucoup qui limitent les templates à des choses simple, genre tableau. Mais j'en vois aussi beaucoup qui sont obligé à utiliser des compilateurs périmés. Or, je trouve très peu de clients près à payer pour qu'on écrive du code qui ne marcherait que si.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Gabriel Dos Reis wrote:
Olivier Azeau writes:
[...]
| J'ai croisé la route d'un certain nombre d'applis avec du | C++ dedans qui, certes, ne sont probablement pas | représentatives de quoi que ce soit et je n'ai jamais vu un | tel coût rédhibitoire.
Mais, cela peut être un frein à la compréhension des propos des autres. Cela n'est pas parce que tu n'en en as pas vus que cela n'existe pas.
Chose qu'il n'a pas dit. Il va falloir que tu apprends à lire ce qui est écrit, et de ne pas t'enrager contre des choses que personne n'a dit.
Quand on parle de la « plupart », c'est un choix de mots qui dit exprès « non tout » ; qui reconnaît qu'il existe des exceptions. Par la suite, on régarde un peu autour de soi, on régarde ce qui est démandé sur le marché d'emploi, on parle avec les gens qui font des colloques, et on essaie de faire un syntèse. Mais ce n'est jamais très précis ; on arrive à dire « la plupart », mais on ne saurait dire si par « plupart », on entend 70%, 90%, ou 99,9%.
Tout ce que je peux dire, c'est qu'ici, l'expérience d'Olivier correspond à la mienne. Ce qui n'était pas le cas dans d'autres cas.
[...]
| En fait, la remarque de James ne me surprend pas car j'ai | souvent vu de près des parties de systèmes qui ne faisaient | "rien", en tout cas
souvent ne veut pas dire la majorité des cas et il semble que toi et James dites « souvent » et refusez de faire de la place à la partie complémentaire.
Pas du tout. Mais souvent, je m'adresse à tous les programmeurs, et non une petite minorité. Et je n'entre pas dans toutes les options ; j'essaie de me limiter aux cas les plus fréquents.
Parce que je trouve que mes postings sont déjà assez longues comme ça, et que si en plus, je parlais de toutes les exceptions, et les cas moins fréquents...
Si je dis « souvent », ce que je veux dire, c'est « souvent », et non toujours. Si je pense que ça doit être toujours, je dis « toujours » (mais ce n'est pas un mot qui me sert souvent).
Et je suis toujours près à discuter avec quelqu'un dont les expériences sont différentes que les miennes.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| J'ai croisé la route d'un certain nombre d'applis avec du
| C++ dedans qui, certes, ne sont probablement pas
| représentatives de quoi que ce soit et je n'ai jamais vu un
| tel coût rédhibitoire.
Mais, cela peut être un frein à la compréhension des propos
des autres. Cela n'est pas parce que tu n'en en as pas vus que
cela n'existe pas.
Chose qu'il n'a pas dit. Il va falloir que tu apprends à lire ce
qui est écrit, et de ne pas t'enrager contre des choses que
personne n'a dit.
Quand on parle de la « plupart », c'est un choix de mots qui dit
exprès « non tout » ; qui reconnaît qu'il existe des exceptions.
Par la suite, on régarde un peu autour de soi, on régarde ce qui
est démandé sur le marché d'emploi, on parle avec les gens qui
font des colloques, et on essaie de faire un syntèse. Mais ce
n'est jamais très précis ; on arrive à dire « la plupart », mais
on ne saurait dire si par « plupart », on entend 70%, 90%, ou
99,9%.
Tout ce que je peux dire, c'est qu'ici, l'expérience d'Olivier
correspond à la mienne. Ce qui n'était pas le cas dans d'autres
cas.
[...]
| En fait, la remarque de James ne me surprend pas car j'ai
| souvent vu de près des parties de systèmes qui ne faisaient
| "rien", en tout cas
souvent ne veut pas dire la majorité des cas et il semble que
toi et James dites « souvent » et refusez de faire de la place
à la partie complémentaire.
Pas du tout. Mais souvent, je m'adresse à tous les programmeurs,
et non une petite minorité. Et je n'entre pas dans toutes les
options ; j'essaie de me limiter aux cas les plus fréquents.
Parce que je trouve que mes postings sont déjà assez longues
comme ça, et que si en plus, je parlais de toutes les
exceptions, et les cas moins fréquents...
Si je dis « souvent », ce que je veux dire, c'est « souvent »,
et non toujours. Si je pense que ça doit être toujours, je dis
« toujours » (mais ce n'est pas un mot qui me sert souvent).
Et je suis toujours près à discuter avec quelqu'un dont les
expériences sont différentes que les miennes.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| J'ai croisé la route d'un certain nombre d'applis avec du | C++ dedans qui, certes, ne sont probablement pas | représentatives de quoi que ce soit et je n'ai jamais vu un | tel coût rédhibitoire.
Mais, cela peut être un frein à la compréhension des propos des autres. Cela n'est pas parce que tu n'en en as pas vus que cela n'existe pas.
Chose qu'il n'a pas dit. Il va falloir que tu apprends à lire ce qui est écrit, et de ne pas t'enrager contre des choses que personne n'a dit.
Quand on parle de la « plupart », c'est un choix de mots qui dit exprès « non tout » ; qui reconnaît qu'il existe des exceptions. Par la suite, on régarde un peu autour de soi, on régarde ce qui est démandé sur le marché d'emploi, on parle avec les gens qui font des colloques, et on essaie de faire un syntèse. Mais ce n'est jamais très précis ; on arrive à dire « la plupart », mais on ne saurait dire si par « plupart », on entend 70%, 90%, ou 99,9%.
Tout ce que je peux dire, c'est qu'ici, l'expérience d'Olivier correspond à la mienne. Ce qui n'était pas le cas dans d'autres cas.
[...]
| En fait, la remarque de James ne me surprend pas car j'ai | souvent vu de près des parties de systèmes qui ne faisaient | "rien", en tout cas
souvent ne veut pas dire la majorité des cas et il semble que toi et James dites « souvent » et refusez de faire de la place à la partie complémentaire.
Pas du tout. Mais souvent, je m'adresse à tous les programmeurs, et non une petite minorité. Et je n'entre pas dans toutes les options ; j'essaie de me limiter aux cas les plus fréquents.
Parce que je trouve que mes postings sont déjà assez longues comme ça, et que si en plus, je parlais de toutes les exceptions, et les cas moins fréquents...
Si je dis « souvent », ce que je veux dire, c'est « souvent », et non toujours. Si je pense que ça doit être toujours, je dis « toujours » (mais ce n'est pas un mot qui me sert souvent).
Et je suis toujours près à discuter avec quelqu'un dont les expériences sont différentes que les miennes.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Ivan Vecerina wrote:
"Olivier Azeau" wrote in message news:ITTMd.20578$
Ivan Vecerina wrote:
| wrote in message |news: |Quel rapport ? Quand les templates conviennent, on utilise les |templates. Quand l'héritage convient, on utilise l'héritage. Les
|deux sont là pour une raison, et c'est même plutôt rare que |leurs champs d'applications se récouvrent.
On ne perd certainement pas en puissance et en flexibilité en faisant du tout-object et tout-dynamique. Cependant, même dans des applications banales, ceci a un coût souvent rédhibitoire.
Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un synonyme de "la plupart")
Souvent ici est un très doux euphémisme.
Euphémisme pour quoi ? Moi, quand je dis souvent, je veux dire souvent, et non toujours. De même quand je dis « la plupart du temps ». Si je ne veux pas admettre l'exception, je dis « toujours » ou « jamais ».
Voir ma réponse à Alain Naigeon pour voir ce que signifie le "tout-objet et tout-dynamique" dans un language comme SmallTalk. Peux-tu me citer quelques applications commerciales écrites en SmallTalk?
Tout l'environement Visual Age d'IBM. Pas mal de développements chez UBS Zurich (je suppose -- de toute façon, dans le temps, il cherchait toujours des programmeurs connaissant Smalltalk). À un époque, le langage était assez prisé pour des applications de logiciel de marché. Aujourd'hui, je crois, beaucoup se sont rendu compte des dangers inhérants dans la manque de vérification statique des types. Certains, en tout cas -- j'avoue que je ne sais pas si il sont vraiment beaucoup. Mais Smalltalk était (et est) toujours assez rapide pour la plupart des applications.
Il y en a par contre beaucoup d'écrites en Objective-C, language hybride qui permet à certains niveaux de tirer profit d'un dynamisme accru. Hybride étant le mot clef.
Je crois qu'il y en a moins écrites en Objective-C qu'en Smalltalk, mais les milieux qui en aimaient un aimaient souvent l'autre. Parmi les gens avec qui j'ai parlé, la préférence pour Objective-C tenait surtout à la facilité à y integrer d'autres logiciels -- je ne crois pas que Oracle offre une interface Smalltalk, par exemple.
J'ai croisé la route d'un certain nombre d'applis avec du C++ dedans qui, certes, ne sont probablement pas représentatives de quoi que ce soit et je n'ai jamais vu un tel coût rédhibitoire.
Je me demande alors pourquoi on utilise encore le type de base 'char', alors qu'une classe avec des fonctions virtuelles serait certainement plus flexible.
C'est peut-être qu'on veut du code qui marche. Qui est robuste. Flexibilité signifie souvent la possibilité de faire des erreurs dans tous les sens. Alors, il faut être flexible quand on a besoin de l'être, mais il faut aussi faire en sort que le compilateur puisse attrapper la majeur partie des erreurs. Où se situe la ligne de partage dépend de l'application et des circonstances, mais j'ai du mal à concevoir des circonstances où une classe comme std::string contiendrait des fonctions virtuelles. (Note bien que même en Java, c'est une classe finale, dont on ne peut pas dériver. C-à-d encore plus strict que le C++.)
C'est pour pouvoir manipuler des données (relativement) brutes et pas tout-à-fait encapsulée derrière des objets et des messages que l'on doit se résoudre à avoir recours à d'autres formes de dispatching et de réutilisation de code.
C'est quoi ces données brutes ?
Des données qui ne sont pas pleinement encapsulées, car accessibles autrement que par l'envoi de messages interprétés dynamiquement par une classe.
Encapsulation ne veut pas dire uniquement accès à travers des fonctions virtuelles. J'ai eu des applications où la performance était en jeu ; heureusement, tout était bien encapsuler, et que j'ai pû modifier la représentation interne d'une classe complètement.
Utiliser des données « brutes » (comme double[], etc.) directement, c'est en général une recette pour garantir la lenteur de l'application.
Le résultat, en C++, est effectivement que l'on a des champs d'application relativement distincts pour les templates et les fonctions virtuelles/héritages.
En l'état actuel, je vois surtout des champs sociologiques distincts : des connaisseurs++ qui font des templates et les autres.
Qu'est-ce qui distinque ces deux classes (sociales) ? Je ne vois pas ici une dychotomie claire mais un continuum.
C'est un continuum, mais je crois que si on faisait une graphe, ça ne serait pas une ligne plate, ni même une courbe regulière, mais qu'il y aurait des bosses très prononcées à certains points. Où exactement, je suis moins sûr (encore que quand je parle avec des gens comme Dave Abrahams ou Scott Meyers sur le niveau et les connaissances des gens qu'ils rencontrent dans leurs séminaires, j'ai mes doutes sur la hauteur des bosses sur la côté utilisation intensive des templates).
|Si tu régardes autour de toi, tu verras que la plupart des |programmes font bien peu de choses, en somme.
Qu'est-ce qui définit "la plupart" ? La même chose que ce qui définit "souvent".
Peut-on comparer "la plupart des programmes font bien peu de choses" à "le coût du tout-objet tout-dynamique est (souvent) redhibitoire" ?
Peut-être. (Mais disons qu'il faudrait commencer par définir « bien peu de choses ». Le programme dans ton portable fait tout ce qu'il faut, et probablement pas mal en plus, sans pour autant qu'il surcharge le CPU ni qu'il ait besoin des mésures d'optimisation particulière.) Dans la deuxième phrase, j'ai bien quelque problèmes. D'abord, parce que tout-objet ne signifie pas (ou ne doit pas signifier) tout-dynamique ; même des anciens du monde de Smalltalk (comme Kent Beck) argue aujourd'hui contre la généricité prématurée. L'objet, c'est un moyen de conception qui peut se refleter dans le code. Le dynamique, c'est un outil dont on se sert quand on en a besoin.
L'autre chose, c'est quand on parle d'un « coût redhibitoire », et il n'est pas question du bon choix des algorithmes, j'ai mes doutes. Si je passais toutes les fonctions en virtuelle dans mon application, elle serait nettement moins robuste, mais elle ne serait pas mésurablement moins rapide -- il me faut mes 10 millisecondes pour l'écriture disque, quoi qui arrive, et je passe déjà moins de 1% du temps CPU dans les appels de fonctions. Alors, même si le temps de l'appel se multiplier par 5, la différence ne serait pas mésurable sur l'ensemble.
....
Je suis certain qu'il n'y avait aucun jugement personnel dans la remarque mais il faut quand même avouer que les besoins en connaisseurs de C++ de haut niveau (j'entends par là le besoin d'une connaissance qui va au delà d'une programmation à la Java) ne courent pas les rues (ou alors c'est que ceux qui en ont besoin l'ignorent)
Il se pourrait bien que ce dernier point soit correct.
Espérons-le, parce que le niveau réel n'est pas toujours terrible.
Pour le reste, je prendrais presque ton commentaire pour un compliment, si j'osais. Mon domaine, c'est plutôt la conception d'applications médicales, incluant souvent imagerie, simulations, et/ou robotique.
Le traitement d'image c'est un domaine que j'inclurai sous la vocable « numérique » ; c'est en tout cas un domaine où les cycles CPU jouent un rôle. En revanche, en robotique... Ce n'était pas le cas dans les applications que je connais dans le domaine (robots de construction automobile).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ivan Vecerina wrote:
"Olivier Azeau"
<read.my.name.and.email.to.firstname@lastname.com> wrote in
message news:ITTMd.20578$Of5.13573@nntpserver.swip.net...
Ivan Vecerina wrote:
|<kanze@gabi-soft.fr> wrote in message
|news:1107507856.068380.121410@l41g2000cwc.googlegroups.com...
|Quel rapport ? Quand les templates conviennent, on utilise les
|templates. Quand l'héritage convient, on utilise l'héritage.
Les
|deux sont là pour une raison, et c'est même plutôt rare que
|leurs champs d'applications se récouvrent.
On ne perd certainement pas en puissance et en flexibilité
en faisant du tout-object et tout-dynamique. Cependant,
même dans des applications banales, ceci a un coût souvent
rédhibitoire.
Qu'est-ce qui définit "souvent" ? (qui finalement n'est
qu'un synonyme de "la plupart")
Souvent ici est un très doux euphémisme.
Euphémisme pour quoi ? Moi, quand je dis souvent, je veux dire
souvent, et non toujours. De même quand je dis « la plupart du
temps ». Si je ne veux pas admettre l'exception, je dis
« toujours » ou « jamais ».
Voir ma réponse à Alain Naigeon pour voir ce que signifie le
"tout-objet et tout-dynamique" dans un language comme
SmallTalk. Peux-tu me citer quelques applications commerciales
écrites en SmallTalk?
Tout l'environement Visual Age d'IBM. Pas mal de développements
chez UBS Zurich (je suppose -- de toute façon, dans le temps, il
cherchait toujours des programmeurs connaissant Smalltalk). À un
époque, le langage était assez prisé pour des applications de
logiciel de marché. Aujourd'hui, je crois, beaucoup se sont
rendu compte des dangers inhérants dans la manque de
vérification statique des types. Certains, en tout cas --
j'avoue que je ne sais pas si il sont vraiment beaucoup. Mais
Smalltalk était (et est) toujours assez rapide pour la plupart
des applications.
Il y en a par contre beaucoup d'écrites en Objective-C,
language hybride qui permet à certains niveaux de tirer profit
d'un dynamisme accru. Hybride étant le mot clef.
Je crois qu'il y en a moins écrites en Objective-C qu'en
Smalltalk, mais les milieux qui en aimaient un aimaient souvent
l'autre. Parmi les gens avec qui j'ai parlé, la préférence pour
Objective-C tenait surtout à la facilité à y integrer d'autres
logiciels -- je ne crois pas que Oracle offre une interface
Smalltalk, par exemple.
J'ai croisé la route d'un certain nombre d'applis avec du
C++ dedans qui, certes, ne sont probablement pas
représentatives de quoi que ce soit et je n'ai jamais vu un
tel coût rédhibitoire.
Je me demande alors pourquoi on utilise encore le type de base
'char', alors qu'une classe avec des fonctions virtuelles
serait certainement plus flexible.
C'est peut-être qu'on veut du code qui marche. Qui est robuste.
Flexibilité signifie souvent la possibilité de faire des erreurs
dans tous les sens. Alors, il faut être flexible quand on a
besoin de l'être, mais il faut aussi faire en sort que le
compilateur puisse attrapper la majeur partie des erreurs. Où se
situe la ligne de partage dépend de l'application et des
circonstances, mais j'ai du mal à concevoir des circonstances où
une classe comme std::string contiendrait des fonctions
virtuelles. (Note bien que même en Java, c'est une classe
finale, dont on ne peut pas dériver. C-à-d encore plus strict
que le C++.)
C'est pour pouvoir manipuler des données (relativement)
brutes et pas tout-à-fait encapsulée derrière des objets et
des messages que l'on doit se résoudre à avoir recours à
d'autres formes de dispatching et de réutilisation de code.
C'est quoi ces données brutes ?
Des données qui ne sont pas pleinement encapsulées, car
accessibles autrement que par l'envoi de messages interprétés
dynamiquement par une classe.
Encapsulation ne veut pas dire uniquement accès à travers des
fonctions virtuelles. J'ai eu des applications où la performance
était en jeu ; heureusement, tout était bien encapsuler, et que
j'ai pû modifier la représentation interne d'une classe
complètement.
Utiliser des données « brutes » (comme double[], etc.)
directement, c'est en général une recette pour garantir la
lenteur de l'application.
Le résultat, en C++, est effectivement que l'on a des
champs d'application relativement distincts pour les
templates et les fonctions virtuelles/héritages.
En l'état actuel, je vois surtout des champs sociologiques
distincts : des connaisseurs++ qui font des templates et les
autres.
Qu'est-ce qui distinque ces deux classes (sociales) ? Je ne
vois pas ici une dychotomie claire mais un continuum.
C'est un continuum, mais je crois que si on faisait une graphe,
ça ne serait pas une ligne plate, ni même une courbe regulière,
mais qu'il y aurait des bosses très prononcées à certains
points. Où exactement, je suis moins sûr (encore que quand je
parle avec des gens comme Dave Abrahams ou Scott Meyers sur le
niveau et les connaissances des gens qu'ils rencontrent dans
leurs séminaires, j'ai mes doutes sur la hauteur des bosses sur
la côté utilisation intensive des templates).
|Si tu régardes autour de toi, tu verras que la plupart des
|programmes font bien peu de choses, en somme.
Qu'est-ce qui définit "la plupart" ? La même chose que ce
qui définit "souvent".
Peut-on comparer "la plupart des programmes font bien peu de
choses" à "le coût du tout-objet tout-dynamique est (souvent)
redhibitoire" ?
Peut-être. (Mais disons qu'il faudrait commencer par définir
« bien peu de choses ». Le programme dans ton portable fait tout
ce qu'il faut, et probablement pas mal en plus, sans pour autant
qu'il surcharge le CPU ni qu'il ait besoin des mésures
d'optimisation particulière.) Dans la deuxième phrase, j'ai bien
quelque problèmes. D'abord, parce que tout-objet ne signifie pas
(ou ne doit pas signifier) tout-dynamique ; même des anciens du
monde de Smalltalk (comme Kent Beck) argue aujourd'hui contre la
généricité prématurée. L'objet, c'est un moyen de conception qui
peut se refleter dans le code. Le dynamique, c'est un outil dont
on se sert quand on en a besoin.
L'autre chose, c'est quand on parle d'un « coût redhibitoire »,
et il n'est pas question du bon choix des algorithmes, j'ai mes
doutes. Si je passais toutes les fonctions en virtuelle dans mon
application, elle serait nettement moins robuste, mais elle ne
serait pas mésurablement moins rapide -- il me faut mes 10
millisecondes pour l'écriture disque, quoi qui arrive, et je
passe déjà moins de 1% du temps CPU dans les appels de
fonctions. Alors, même si le temps de l'appel se multiplier par
5, la différence ne serait pas mésurable sur l'ensemble.
....
Je suis certain qu'il n'y avait aucun jugement personnel
dans la remarque mais il faut quand même avouer que les
besoins en connaisseurs de C++ de haut niveau (j'entends par
là le besoin d'une connaissance qui va au delà d'une
programmation à la Java) ne courent pas les rues (ou alors
c'est que ceux qui en ont besoin l'ignorent)
Il se pourrait bien que ce dernier point soit correct.
Espérons-le, parce que le niveau réel n'est pas toujours
terrible.
Pour le reste, je prendrais presque ton commentaire pour un
compliment, si j'osais. Mon domaine, c'est plutôt la
conception d'applications médicales, incluant souvent
imagerie, simulations, et/ou robotique.
Le traitement d'image c'est un domaine que j'inclurai sous la
vocable « numérique » ; c'est en tout cas un domaine où les
cycles CPU jouent un rôle. En revanche, en robotique... Ce
n'était pas le cas dans les applications que je connais dans le
domaine (robots de construction automobile).
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Olivier Azeau" wrote in message news:ITTMd.20578$
Ivan Vecerina wrote:
| wrote in message |news: |Quel rapport ? Quand les templates conviennent, on utilise les |templates. Quand l'héritage convient, on utilise l'héritage. Les
|deux sont là pour une raison, et c'est même plutôt rare que |leurs champs d'applications se récouvrent.
On ne perd certainement pas en puissance et en flexibilité en faisant du tout-object et tout-dynamique. Cependant, même dans des applications banales, ceci a un coût souvent rédhibitoire.
Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un synonyme de "la plupart")
Souvent ici est un très doux euphémisme.
Euphémisme pour quoi ? Moi, quand je dis souvent, je veux dire souvent, et non toujours. De même quand je dis « la plupart du temps ». Si je ne veux pas admettre l'exception, je dis « toujours » ou « jamais ».
Voir ma réponse à Alain Naigeon pour voir ce que signifie le "tout-objet et tout-dynamique" dans un language comme SmallTalk. Peux-tu me citer quelques applications commerciales écrites en SmallTalk?
Tout l'environement Visual Age d'IBM. Pas mal de développements chez UBS Zurich (je suppose -- de toute façon, dans le temps, il cherchait toujours des programmeurs connaissant Smalltalk). À un époque, le langage était assez prisé pour des applications de logiciel de marché. Aujourd'hui, je crois, beaucoup se sont rendu compte des dangers inhérants dans la manque de vérification statique des types. Certains, en tout cas -- j'avoue que je ne sais pas si il sont vraiment beaucoup. Mais Smalltalk était (et est) toujours assez rapide pour la plupart des applications.
Il y en a par contre beaucoup d'écrites en Objective-C, language hybride qui permet à certains niveaux de tirer profit d'un dynamisme accru. Hybride étant le mot clef.
Je crois qu'il y en a moins écrites en Objective-C qu'en Smalltalk, mais les milieux qui en aimaient un aimaient souvent l'autre. Parmi les gens avec qui j'ai parlé, la préférence pour Objective-C tenait surtout à la facilité à y integrer d'autres logiciels -- je ne crois pas que Oracle offre une interface Smalltalk, par exemple.
J'ai croisé la route d'un certain nombre d'applis avec du C++ dedans qui, certes, ne sont probablement pas représentatives de quoi que ce soit et je n'ai jamais vu un tel coût rédhibitoire.
Je me demande alors pourquoi on utilise encore le type de base 'char', alors qu'une classe avec des fonctions virtuelles serait certainement plus flexible.
C'est peut-être qu'on veut du code qui marche. Qui est robuste. Flexibilité signifie souvent la possibilité de faire des erreurs dans tous les sens. Alors, il faut être flexible quand on a besoin de l'être, mais il faut aussi faire en sort que le compilateur puisse attrapper la majeur partie des erreurs. Où se situe la ligne de partage dépend de l'application et des circonstances, mais j'ai du mal à concevoir des circonstances où une classe comme std::string contiendrait des fonctions virtuelles. (Note bien que même en Java, c'est une classe finale, dont on ne peut pas dériver. C-à-d encore plus strict que le C++.)
C'est pour pouvoir manipuler des données (relativement) brutes et pas tout-à-fait encapsulée derrière des objets et des messages que l'on doit se résoudre à avoir recours à d'autres formes de dispatching et de réutilisation de code.
C'est quoi ces données brutes ?
Des données qui ne sont pas pleinement encapsulées, car accessibles autrement que par l'envoi de messages interprétés dynamiquement par une classe.
Encapsulation ne veut pas dire uniquement accès à travers des fonctions virtuelles. J'ai eu des applications où la performance était en jeu ; heureusement, tout était bien encapsuler, et que j'ai pû modifier la représentation interne d'une classe complètement.
Utiliser des données « brutes » (comme double[], etc.) directement, c'est en général une recette pour garantir la lenteur de l'application.
Le résultat, en C++, est effectivement que l'on a des champs d'application relativement distincts pour les templates et les fonctions virtuelles/héritages.
En l'état actuel, je vois surtout des champs sociologiques distincts : des connaisseurs++ qui font des templates et les autres.
Qu'est-ce qui distinque ces deux classes (sociales) ? Je ne vois pas ici une dychotomie claire mais un continuum.
C'est un continuum, mais je crois que si on faisait une graphe, ça ne serait pas une ligne plate, ni même une courbe regulière, mais qu'il y aurait des bosses très prononcées à certains points. Où exactement, je suis moins sûr (encore que quand je parle avec des gens comme Dave Abrahams ou Scott Meyers sur le niveau et les connaissances des gens qu'ils rencontrent dans leurs séminaires, j'ai mes doutes sur la hauteur des bosses sur la côté utilisation intensive des templates).
|Si tu régardes autour de toi, tu verras que la plupart des |programmes font bien peu de choses, en somme.
Qu'est-ce qui définit "la plupart" ? La même chose que ce qui définit "souvent".
Peut-on comparer "la plupart des programmes font bien peu de choses" à "le coût du tout-objet tout-dynamique est (souvent) redhibitoire" ?
Peut-être. (Mais disons qu'il faudrait commencer par définir « bien peu de choses ». Le programme dans ton portable fait tout ce qu'il faut, et probablement pas mal en plus, sans pour autant qu'il surcharge le CPU ni qu'il ait besoin des mésures d'optimisation particulière.) Dans la deuxième phrase, j'ai bien quelque problèmes. D'abord, parce que tout-objet ne signifie pas (ou ne doit pas signifier) tout-dynamique ; même des anciens du monde de Smalltalk (comme Kent Beck) argue aujourd'hui contre la généricité prématurée. L'objet, c'est un moyen de conception qui peut se refleter dans le code. Le dynamique, c'est un outil dont on se sert quand on en a besoin.
L'autre chose, c'est quand on parle d'un « coût redhibitoire », et il n'est pas question du bon choix des algorithmes, j'ai mes doutes. Si je passais toutes les fonctions en virtuelle dans mon application, elle serait nettement moins robuste, mais elle ne serait pas mésurablement moins rapide -- il me faut mes 10 millisecondes pour l'écriture disque, quoi qui arrive, et je passe déjà moins de 1% du temps CPU dans les appels de fonctions. Alors, même si le temps de l'appel se multiplier par 5, la différence ne serait pas mésurable sur l'ensemble.
....
Je suis certain qu'il n'y avait aucun jugement personnel dans la remarque mais il faut quand même avouer que les besoins en connaisseurs de C++ de haut niveau (j'entends par là le besoin d'une connaissance qui va au delà d'une programmation à la Java) ne courent pas les rues (ou alors c'est que ceux qui en ont besoin l'ignorent)
Il se pourrait bien que ce dernier point soit correct.
Espérons-le, parce que le niveau réel n'est pas toujours terrible.
Pour le reste, je prendrais presque ton commentaire pour un compliment, si j'osais. Mon domaine, c'est plutôt la conception d'applications médicales, incluant souvent imagerie, simulations, et/ou robotique.
Le traitement d'image c'est un domaine que j'inclurai sous la vocable « numérique » ; c'est en tout cas un domaine où les cycles CPU jouent un rôle. En revanche, en robotique... Ce n'était pas le cas dans les applications que je connais dans le domaine (robots de construction automobile).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote: | > Olivier Azeau | > writes: | | > [...] | | > | J'ai croisé la route d'un certain nombre d'applis avec du | > | C++ dedans qui, certes, ne sont probablement pas | > | représentatives de quoi que ce soit et je n'ai jamais vu un | > | tel coût rédhibitoire. | | > Mais, cela peut être un frein à la compréhension des propos | > des autres. Cela n'est pas parce que tu n'en en as pas vus que | > cela n'existe pas. | | Chose qu'il n'a pas dit. Il va falloir que tu apprends à lire ce | qui est écrit,
As-tu essayé de suivre ton propre conseil ? S'il n'a pas d'effet sur toi, pourquoi penses-tu que tu devrais le donner à d'autres ?
| et de ne pas t'enrager contre des choses que personne n'a dit. | | Quand on parle de la « plupart », c'est un choix de mots qui dit | exprès « non tout » ; qui reconnaît qu'il existe des exceptions.
En l'occurance, le passage auquel je répondais disait
# J'ai croisé la route *d'un certain nombre* d'applis avec du # C++ dedans qui, certes, ne sont probablement pas # représentatives de quoi que ce soit et j'ai jamais vu un tel # coût rédhibitoire.
(l'emphase est mienne).
James, d'abord, enlève la poutre de tes yeux.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis wrote:
| > Olivier Azeau
| > <read.my.name.and.email.to.firstname@lastname.com> writes:
|
| > [...]
|
| > | J'ai croisé la route d'un certain nombre d'applis avec du
| > | C++ dedans qui, certes, ne sont probablement pas
| > | représentatives de quoi que ce soit et je n'ai jamais vu un
| > | tel coût rédhibitoire.
|
| > Mais, cela peut être un frein à la compréhension des propos
| > des autres. Cela n'est pas parce que tu n'en en as pas vus que
| > cela n'existe pas.
|
| Chose qu'il n'a pas dit. Il va falloir que tu apprends à lire ce
| qui est écrit,
As-tu essayé de suivre ton propre conseil ? S'il n'a pas d'effet sur
toi, pourquoi penses-tu que tu devrais le donner à d'autres ?
| et de ne pas t'enrager contre des choses que personne n'a dit.
|
| Quand on parle de la « plupart », c'est un choix de mots qui dit
| exprès « non tout » ; qui reconnaît qu'il existe des exceptions.
En l'occurance, le passage auquel je répondais disait
# J'ai croisé la route *d'un certain nombre* d'applis avec du
# C++ dedans qui, certes, ne sont probablement pas
# représentatives de quoi que ce soit et j'ai jamais vu un tel
# coût rédhibitoire.
| Gabriel Dos Reis wrote: | > Olivier Azeau | > writes: | | > [...] | | > | J'ai croisé la route d'un certain nombre d'applis avec du | > | C++ dedans qui, certes, ne sont probablement pas | > | représentatives de quoi que ce soit et je n'ai jamais vu un | > | tel coût rédhibitoire. | | > Mais, cela peut être un frein à la compréhension des propos | > des autres. Cela n'est pas parce que tu n'en en as pas vus que | > cela n'existe pas. | | Chose qu'il n'a pas dit. Il va falloir que tu apprends à lire ce | qui est écrit,
As-tu essayé de suivre ton propre conseil ? S'il n'a pas d'effet sur toi, pourquoi penses-tu que tu devrais le donner à d'autres ?
| et de ne pas t'enrager contre des choses que personne n'a dit. | | Quand on parle de la « plupart », c'est un choix de mots qui dit | exprès « non tout » ; qui reconnaît qu'il existe des exceptions.
En l'occurance, le passage auquel je répondais disait
# J'ai croisé la route *d'un certain nombre* d'applis avec du # C++ dedans qui, certes, ne sont probablement pas # représentatives de quoi que ce soit et j'ai jamais vu un tel # coût rédhibitoire.
(l'emphase est mienne).
James, d'abord, enlève la poutre de tes yeux.
-- Gaby
Gabriel Dos Reis
writes:
| Olivier Azeau wrote: | > Ivan Vecerina wrote: | > > | wrote in message | > > |news: | > > |Quel rapport ? Quand les templates conviennent, on utilise | > > |les templates. Quand l'héritage convient, on utilise | > > |l'héritage. Les deux sont là pour une raison, et c'est même | > > |plutôt rare que leurs champs d'applications se récouvrent. | | > > On ne perd certainement pas en puissance et en flexibilité | > > en faisant du tout-object et tout-dynamique. Cependant, même | > > dans des applications banales, ceci a un coût souvent | > > rédhibitoire. | | > Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un | > synonyme de "la plupart") | | Pas forcement. Je mange souvent (plusieurs fois par jour, même), | mais je ne passe pas la plupart de mon temps à manger.
C'est ce que tu prétends. Après tout, on n'a pas de preuve. ;-p
-- Gaby
kanze@gabi-soft.fr writes:
| Olivier Azeau wrote:
| > Ivan Vecerina wrote:
| > > |<kanze@gabi-soft.fr> wrote in message
| > > |news:1107507856.068380.121410@l41g2000cwc.googlegroups.com...
| > > |Quel rapport ? Quand les templates conviennent, on utilise
| > > |les templates. Quand l'héritage convient, on utilise
| > > |l'héritage. Les deux sont là pour une raison, et c'est même
| > > |plutôt rare que leurs champs d'applications se récouvrent.
|
| > > On ne perd certainement pas en puissance et en flexibilité
| > > en faisant du tout-object et tout-dynamique. Cependant, même
| > > dans des applications banales, ceci a un coût souvent
| > > rédhibitoire.
|
| > Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un
| > synonyme de "la plupart")
|
| Pas forcement. Je mange souvent (plusieurs fois par jour, même),
| mais je ne passe pas la plupart de mon temps à manger.
C'est ce que tu prétends. Après tout, on n'a pas de preuve. ;-p
| Olivier Azeau wrote: | > Ivan Vecerina wrote: | > > | wrote in message | > > |news: | > > |Quel rapport ? Quand les templates conviennent, on utilise | > > |les templates. Quand l'héritage convient, on utilise | > > |l'héritage. Les deux sont là pour une raison, et c'est même | > > |plutôt rare que leurs champs d'applications se récouvrent. | | > > On ne perd certainement pas en puissance et en flexibilité | > > en faisant du tout-object et tout-dynamique. Cependant, même | > > dans des applications banales, ceci a un coût souvent | > > rédhibitoire. | | > Qu'est-ce qui définit "souvent" ? (qui finalement n'est qu'un | > synonyme de "la plupart") | | Pas forcement. Je mange souvent (plusieurs fois par jour, même), | mais je ne passe pas la plupart de mon temps à manger.
C'est ce que tu prétends. Après tout, on n'a pas de preuve. ;-p
-- Gaby
kanze
Gabriel Dos Reis wrote:
"Ivan Vecerina" writes:
[...]
| |Tu fais donc beaucoup de calcul pour peu d'affichage, sur | |de grands jeux de données en mémoire. Ce sont typiquement | |des applications numériques où c'est le cas, ou peut-être | |les jeux. Mais ce n'est pas typique de beaucoup de | |programmeurs ; si je régarde dans les démandes d'emploi, | |par exemple, il y a fort peu de démande pour les matheux, | |en dehors des banques (et les programmes de marché sont un | |peu spéciaux comme applications numériques, parce qu'ils ne | |traitent en général qu'un petit jeu de données, en lui | |appliquant des formules on ne peut plus compliquées).
| Je suis impressionné par la portée de l'interprétation et du | jugement que vous vous permettez de faire. Le "matheux qui | fait beaucoup de calcul pour peu d'affichage, sans | perspective professionnelle sinon dans le bancaire pour | faire des trucs très compliqués avec peu de données" avait | jusqu'à présent une certaine considération pour vous.
| Voilà qui me coupe l'envie de poursuivre.
Patience. Pour je ne sais quelle raison, James a tendance à faire passer pour secondaire tout ce qui a relation de près ou de loin au monde scientifique.
Seulement numériquement. Pour la reste, c'est ton complexe de persicution qui joue, peut-être. Ou simplement ton inabilité d'admettre qu'il existe d'autres critères que les tiens.
Probablement, parce qu'il part du principe que tout ce qu'il ne connaît pas n'existe.
Ne juge pas les autres par toi-même.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| |Tu fais donc beaucoup de calcul pour peu d'affichage, sur
| |de grands jeux de données en mémoire. Ce sont typiquement
| |des applications numériques où c'est le cas, ou peut-être
| |les jeux. Mais ce n'est pas typique de beaucoup de
| |programmeurs ; si je régarde dans les démandes d'emploi,
| |par exemple, il y a fort peu de démande pour les matheux,
| |en dehors des banques (et les programmes de marché sont un
| |peu spéciaux comme applications numériques, parce qu'ils ne
| |traitent en général qu'un petit jeu de données, en lui
| |appliquant des formules on ne peut plus compliquées).
| Je suis impressionné par la portée de l'interprétation et du
| jugement que vous vous permettez de faire. Le "matheux qui
| fait beaucoup de calcul pour peu d'affichage, sans
| perspective professionnelle sinon dans le bancaire pour
| faire des trucs très compliqués avec peu de données" avait
| jusqu'à présent une certaine considération pour vous.
| Voilà qui me coupe l'envie de poursuivre.
Patience.
Pour je ne sais quelle raison, James a tendance à faire passer
pour secondaire tout ce qui a relation de près ou de loin au
monde scientifique.
Seulement numériquement. Pour la reste, c'est ton complexe de
persicution qui joue, peut-être. Ou simplement ton inabilité
d'admettre qu'il existe d'autres critères que les tiens.
Probablement, parce qu'il part du principe que tout ce qu'il
ne connaît pas n'existe.
Ne juge pas les autres par toi-même.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| |Tu fais donc beaucoup de calcul pour peu d'affichage, sur | |de grands jeux de données en mémoire. Ce sont typiquement | |des applications numériques où c'est le cas, ou peut-être | |les jeux. Mais ce n'est pas typique de beaucoup de | |programmeurs ; si je régarde dans les démandes d'emploi, | |par exemple, il y a fort peu de démande pour les matheux, | |en dehors des banques (et les programmes de marché sont un | |peu spéciaux comme applications numériques, parce qu'ils ne | |traitent en général qu'un petit jeu de données, en lui | |appliquant des formules on ne peut plus compliquées).
| Je suis impressionné par la portée de l'interprétation et du | jugement que vous vous permettez de faire. Le "matheux qui | fait beaucoup de calcul pour peu d'affichage, sans | perspective professionnelle sinon dans le bancaire pour | faire des trucs très compliqués avec peu de données" avait | jusqu'à présent une certaine considération pour vous.
| Voilà qui me coupe l'envie de poursuivre.
Patience. Pour je ne sais quelle raison, James a tendance à faire passer pour secondaire tout ce qui a relation de près ou de loin au monde scientifique.
Seulement numériquement. Pour la reste, c'est ton complexe de persicution qui joue, peut-être. Ou simplement ton inabilité d'admettre qu'il existe d'autres critères que les tiens.
Probablement, parce qu'il part du principe que tout ce qu'il ne connaît pas n'existe.
Ne juge pas les autres par toi-même.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
writes:
| Ivan Vecerina wrote: | > "Alain Naigeon" wrote in message | > news:4204038c$0$602$ | | > > "Ivan Vecerina" a | > > écrit dans le message news: cu0s5d$jn2$ | > >> On ne perd certainement pas en puissance et en flexibilité | > >> en faisant du tout-object et tout-dynamique. Cependant, | > >> même dans des applications banales, ceci a un coût souvent | > >> rédhibitoire. | | > > C'est marrant, quand il s'est agi de passer de C à C++, on | > > affirmait le contraire à ceux qui émettaient des doutes (ou | > > qui ne voyaient pas ce qu'on gagnait en temps de mise au | > > point et en sécurité) | | > L'orienté-objet introduit par le C++ n'a rien à voir avec le | > dynamisme quasi-total offert par un language comme SmallTalk. | | Oui et non. La notion de la résolution à l'execution y est. Mais | comme Eiffel, il ne rénonce pas à la vérification statique des | types, et je crois que Stroustrup a été influencé par Meyers | pour certaines choses.
BS avait formulé dès 77-78 qu'il avait vraiment besoin de la vérification statique des types et c'était à la base de ses travaux avec « C with Classes. » Voir D&E.
Ce que je sais de source sûre, c'est qu'il avait décidé de ne pas tomber dans la trappe, comme Eiffel, avec la contravariance.
| (En revanche, je ne suis pas sûr qu'il | n'a pas introduit l'héritage avant de connaître l'oeuvre de | Meyers. Il faudrait lui démander.)
C'est simple : C++ est influencé directement par Simula et Simula avait la notion d'héritage, qu'on retrouvera dans « C with Classes ». Et c'était quand déjà ? Voir D&E.
-- Gaby
kanze@gabi-soft.fr writes:
| Ivan Vecerina wrote:
| > "Alain Naigeon" <anaigeon@free.fr> wrote in message
| > news:4204038c$0$602$636a15ce@news.free.fr...
|
| > > "Ivan Vecerina" <INVALID_use_webform_instead@vecerina.com> a
| > > écrit dans le message news: cu0s5d$jn2$1@news.hispeed.ch...
| > >> On ne perd certainement pas en puissance et en flexibilité
| > >> en faisant du tout-object et tout-dynamique. Cependant,
| > >> même dans des applications banales, ceci a un coût souvent
| > >> rédhibitoire.
|
| > > C'est marrant, quand il s'est agi de passer de C à C++, on
| > > affirmait le contraire à ceux qui émettaient des doutes (ou
| > > qui ne voyaient pas ce qu'on gagnait en temps de mise au
| > > point et en sécurité)
|
| > L'orienté-objet introduit par le C++ n'a rien à voir avec le
| > dynamisme quasi-total offert par un language comme SmallTalk.
|
| Oui et non. La notion de la résolution à l'execution y est. Mais
| comme Eiffel, il ne rénonce pas à la vérification statique des
| types, et je crois que Stroustrup a été influencé par Meyers
| pour certaines choses.
BS avait formulé dès 77-78 qu'il avait vraiment besoin de la
vérification statique des types et c'était à la base de ses travaux
avec « C with Classes. » Voir D&E.
Ce que je sais de source sûre, c'est qu'il avait décidé de ne pas
tomber dans la trappe, comme Eiffel, avec la contravariance.
| (En revanche, je ne suis pas sûr qu'il
| n'a pas introduit l'héritage avant de connaître l'oeuvre de
| Meyers. Il faudrait lui démander.)
C'est simple : C++ est influencé directement par Simula et Simula
avait la notion d'héritage, qu'on retrouvera dans « C with Classes ».
Et c'était quand déjà ? Voir D&E.
| Ivan Vecerina wrote: | > "Alain Naigeon" wrote in message | > news:4204038c$0$602$ | | > > "Ivan Vecerina" a | > > écrit dans le message news: cu0s5d$jn2$ | > >> On ne perd certainement pas en puissance et en flexibilité | > >> en faisant du tout-object et tout-dynamique. Cependant, | > >> même dans des applications banales, ceci a un coût souvent | > >> rédhibitoire. | | > > C'est marrant, quand il s'est agi de passer de C à C++, on | > > affirmait le contraire à ceux qui émettaient des doutes (ou | > > qui ne voyaient pas ce qu'on gagnait en temps de mise au | > > point et en sécurité) | | > L'orienté-objet introduit par le C++ n'a rien à voir avec le | > dynamisme quasi-total offert par un language comme SmallTalk. | | Oui et non. La notion de la résolution à l'execution y est. Mais | comme Eiffel, il ne rénonce pas à la vérification statique des | types, et je crois que Stroustrup a été influencé par Meyers | pour certaines choses.
BS avait formulé dès 77-78 qu'il avait vraiment besoin de la vérification statique des types et c'était à la base de ses travaux avec « C with Classes. » Voir D&E.
Ce que je sais de source sûre, c'est qu'il avait décidé de ne pas tomber dans la trappe, comme Eiffel, avec la contravariance.
| (En revanche, je ne suis pas sûr qu'il | n'a pas introduit l'héritage avant de connaître l'oeuvre de | Meyers. Il faudrait lui démander.)
C'est simple : C++ est influencé directement par Simula et Simula avait la notion d'héritage, qu'on retrouvera dans « C with Classes ». Et c'était quand déjà ? Voir D&E.
-- Gaby
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote: | > "Ivan Vecerina" writes: | | > [...] | | > | |Tu fais donc beaucoup de calcul pour peu d'affichage, sur | > | |de grands jeux de données en mémoire. Ce sont typiquement | > | |des applications numériques où c'est le cas, ou peut-être | > | |les jeux. Mais ce n'est pas typique de beaucoup de | > | |programmeurs ; si je régarde dans les démandes d'emploi, | > | |par exemple, il y a fort peu de démande pour les matheux, | > | |en dehors des banques (et les programmes de marché sont un | > | |peu spéciaux comme applications numériques, parce qu'ils ne | > | |traitent en général qu'un petit jeu de données, en lui | > | |appliquant des formules on ne peut plus compliquées). | | > | Je suis impressionné par la portée de l'interprétation et du | > | jugement que vous vous permettez de faire. Le "matheux qui | > | fait beaucoup de calcul pour peu d'affichage, sans | > | perspective professionnelle sinon dans le bancaire pour | > | faire des trucs très compliqués avec peu de données" avait | > | jusqu'à présent une certaine considération pour vous. | | > | Voilà qui me coupe l'envie de poursuivre. | | > Patience. | > Pour je ne sais quelle raison, James a tendance à faire passer | > pour secondaire tout ce qui a relation de près ou de loin au | > monde scientifique. | | Seulement numériquement.
Oh ?
| Pour la reste, c'est ton complexe de | persicution qui joue, peut-être. Ou simplement ton inabilité | d'admettre qu'il existe d'autres critères que les tiens.
complexe de quoi ?
| > Probablement, parce qu'il part du principe que tout ce qu'il | > ne connaît pas n'existe. | | Ne juge pas les autres par toi-même.
Pourquoi tu ne suis pas ton propre conseil ? Tu viens juste de l'enfreindre par au moins deux fois. Tsss. Tsss.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis wrote:
| > "Ivan Vecerina" <INVALID_use_webform_instead@vecerina.com> writes:
|
| > [...]
|
| > | |Tu fais donc beaucoup de calcul pour peu d'affichage, sur
| > | |de grands jeux de données en mémoire. Ce sont typiquement
| > | |des applications numériques où c'est le cas, ou peut-être
| > | |les jeux. Mais ce n'est pas typique de beaucoup de
| > | |programmeurs ; si je régarde dans les démandes d'emploi,
| > | |par exemple, il y a fort peu de démande pour les matheux,
| > | |en dehors des banques (et les programmes de marché sont un
| > | |peu spéciaux comme applications numériques, parce qu'ils ne
| > | |traitent en général qu'un petit jeu de données, en lui
| > | |appliquant des formules on ne peut plus compliquées).
|
| > | Je suis impressionné par la portée de l'interprétation et du
| > | jugement que vous vous permettez de faire. Le "matheux qui
| > | fait beaucoup de calcul pour peu d'affichage, sans
| > | perspective professionnelle sinon dans le bancaire pour
| > | faire des trucs très compliqués avec peu de données" avait
| > | jusqu'à présent une certaine considération pour vous.
|
| > | Voilà qui me coupe l'envie de poursuivre.
|
| > Patience.
| > Pour je ne sais quelle raison, James a tendance à faire passer
| > pour secondaire tout ce qui a relation de près ou de loin au
| > monde scientifique.
|
| Seulement numériquement.
Oh ?
| Pour la reste, c'est ton complexe de
| persicution qui joue, peut-être. Ou simplement ton inabilité
| d'admettre qu'il existe d'autres critères que les tiens.
complexe de quoi ?
| > Probablement, parce qu'il part du principe que tout ce qu'il
| > ne connaît pas n'existe.
|
| Ne juge pas les autres par toi-même.
Pourquoi tu ne suis pas ton propre conseil ? Tu viens juste de
l'enfreindre par au moins deux fois. Tsss. Tsss.
| Gabriel Dos Reis wrote: | > "Ivan Vecerina" writes: | | > [...] | | > | |Tu fais donc beaucoup de calcul pour peu d'affichage, sur | > | |de grands jeux de données en mémoire. Ce sont typiquement | > | |des applications numériques où c'est le cas, ou peut-être | > | |les jeux. Mais ce n'est pas typique de beaucoup de | > | |programmeurs ; si je régarde dans les démandes d'emploi, | > | |par exemple, il y a fort peu de démande pour les matheux, | > | |en dehors des banques (et les programmes de marché sont un | > | |peu spéciaux comme applications numériques, parce qu'ils ne | > | |traitent en général qu'un petit jeu de données, en lui | > | |appliquant des formules on ne peut plus compliquées). | | > | Je suis impressionné par la portée de l'interprétation et du | > | jugement que vous vous permettez de faire. Le "matheux qui | > | fait beaucoup de calcul pour peu d'affichage, sans | > | perspective professionnelle sinon dans le bancaire pour | > | faire des trucs très compliqués avec peu de données" avait | > | jusqu'à présent une certaine considération pour vous. | | > | Voilà qui me coupe l'envie de poursuivre. | | > Patience. | > Pour je ne sais quelle raison, James a tendance à faire passer | > pour secondaire tout ce qui a relation de près ou de loin au | > monde scientifique. | | Seulement numériquement.
Oh ?
| Pour la reste, c'est ton complexe de | persicution qui joue, peut-être. Ou simplement ton inabilité | d'admettre qu'il existe d'autres critères que les tiens.
complexe de quoi ?
| > Probablement, parce qu'il part du principe que tout ce qu'il | > ne connaît pas n'existe. | | Ne juge pas les autres par toi-même.
Pourquoi tu ne suis pas ton propre conseil ? Tu viens juste de l'enfreindre par au moins deux fois. Tsss. Tsss.
-- Gaby
Loïc Joly
Gabriel Dos Reis wrote:
Ce que je sais de source sûre, c'est qu'il avait décidé de ne pas tomber dans la trappe, comme Eiffel, avec la contravariance.
Pourrais tu préciser ce qu'est la contravariance, s'il te plait ?
-- Loïc, qui ne connait que covariance, et se dit qu'il doit y avoir un lien
Gabriel Dos Reis wrote:
Ce que je sais de source sûre, c'est qu'il avait décidé de ne pas
tomber dans la trappe, comme Eiffel, avec la contravariance.
Pourrais tu préciser ce qu'est la contravariance, s'il te plait ?
--
Loïc, qui ne connait que covariance, et se dit qu'il doit y avoir un lien
