Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ La fin de l'héritage ?

La fin de l'héritage ?

103 réponses
Avatar
Olivier Azeau
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>;

| template <class DOCDISP>
| class Application where { DisplaysDocuments<DOCDISP> } {
| public:
| void run() {
| Memo<DOCDISP> memo;
| memo.drawSummary();
| }
| };

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...
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
2 3 4 5 6
Avatar
kanze
Gabriel Dos Reis wrote:
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 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. :-(


Ce qui caractèrise une mode, ce sont les extrèmes. Il y en a
aussi que le rejette d'office parce que c'est nouveau.
(L'argument le plus fréquent, c'est que c'est illisible. Ce qui
est sûr, c'est tout est illisible si tu ne connais pas les
techniques utilisées.)

N'empèche que si je régarde autour de moi, ou je considère les
entretiens d'embauche, ou je parle avec Scott Meyers ou Dave
Abrahams de ce qu'ils voient dans leurs colloques, j'ai
l'impression que la plupart des programmeurs C++ savent à peine
ce que c'est qu'un template, et qu'ils ont encore beaucoup de
mal à simplement se servir de std::vector. N'oublions pas
combien de temps il a fallu pour que l'orientation objet entre
dans les moeurs, et avant ça, la programmation structurée. (Mais
n'oublions pas non plus que les bonnes idées finissent toujours
par s'imposer, à la longue.)

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

Avatar
Ivan Vecerina
"Olivier Azeau" wrote in
message news:HZjMd.19873$
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.
Je dirais plutôt que le C était proche de l'assembleur, voire du fortran.


Le C++ a changé ce contexte (aux forceps).
Je pense qu'il l'a surtout étendu. Progressivement même les développeurs

qui font de l'embarqué exploitent les possibilités du C++, tout en
respectant des contraintes strictes en terme de resources.
"forceps" ? au contraire, certains reprocheront au C++ d'avoir permis
aux programmeurs C de faire trop en douceur un peu d'orienté objet,
sans devoir faire le grand saut...

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.
Le C++ est employé dans des contextes *multiples*: embarqué, système,

numérique, jeux, desktop, traitement de données, communication, etc...

Je ne pense pas que la communauté C ait souffert du succès du C++,
bien au contraire. Le fait que C++ couvre de nouveaux domaines
d'application génère des problèmes de complexité, et peut-être une
communauté plus fractionnée (parce que plus étendue), mais c'est
aussi un puissant trait d'union entre plusieurs domaines d'application.


Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form


Avatar
Olivier Azeau
Ivan Vecerina wrote:
"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.


Si ma réponse semble manquer de courtoisie, veuillez m'en excuser.

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.


Tout ce que tu explicites la, c'est vraiment tres bien (surtout pour la
minorité qui sait s'en servir)
Quand je parle résoudre des problemes d'allocation dans le tas, c'est
pour dire qu'il vaut mieux allouer sur la pile un objet dont la durée
de vie ne dépasse pas un bloc (je caricature mais l'idée est la...)

Et quand je vois en entretien que l'on peut avoir appris a faire du C++
sans savoir expliciter la différence entre un passage par copie et un
passage par référence, je sais que une bonne utilisation des policy
ou smart pointers, ce n'est pas pour demain...



Avatar
Jean-Marc Bourguet
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.


Mon probleme est qu'on reste beaucoup trop facilement dans ce qui est
familier. Je reste interesse par les langages bases sur des concepts
differents de ceux que je connais, meme si je doute que je
programmerais un jour professionnellement avec eux. Decouvrir Haskell
ou Aldor est un enrichissement que je juge favorable a ma capacite
d'ecrire du C++ aujourd'hui. Alors quand je vois que certains n'ont
meme pas une connaissance de choses aussi vieilles de le Lisp ou
Prolog... il y a un probleme. Ils jugent essentielles des choses qui
ne sont qu'accidentelles.

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


C'est le temps qui manque le plus.

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 ?


Ca ne fait pas partie de mon univers. Enfin, le GC on l'a dans le
langage d'extension, mais __gc non.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org



Avatar
Gabriel Dos Reis
Olivier Azeau writes:

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


très certainement.

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

yep.

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

je ne nie pas ce que tu affirmes connaître. Je te fais juste remarque
ue la communauté C++ est très diverse et variée. Ses utilisations
aussi. Comme BS dirait « I don't know what C++ programmers do. »
Je ne sais pas non plus, mais je peux certainement reconnaître des
affirmations basées sur des faits très limités.

-- Gaby
Avatar
Gabriel Dos Reis
"Ivan Vecerina" writes:

[...]

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

Oui. Je suppose que la clé, c'est l'éducation. Et c'est difficile.
Il semble y avoir une quantité phénoménale d'auteurs et de bouquins.
Parmi ceux que j'ai lus, seulement une petite minuscule fraction
semble comprendre la dualité. Il reste encore, à mon avis, de larges
domaines populaires où on fait systématiquement l'opposition template
vs. function virtuelle. Au lieu de les voir, d'une certaine manière,
complémentaires.

-- Gaby
Avatar
Jean-Marc Bourguet
writes:

Jean-Marc Bourguet wrote:
writes:

Jean-Marc Bourguet wrote:
"Olivier Azeau" writes:

Pour un projet donné, faudra-t-il imposer une approche ?


Le polymorphisme parametrique (la genericite) et le
polymorphisme de substitution (celui qui resulte de
l'heritage) ont des domaines d'application differents mais
qui se recoupent un peu.


Très peu, en fait.


Il y a pas mal de chose que tu peux faire en utilisant le
polymorphisme de substitution a la place du polymorphisme
parametrique. Avec plus de travail (il faut parfois faire des
adaptateurs) et en perdant parfois le controle de type.


Il y a souvent des choses qu'on *peut* faire. Mais dans la plupart
des cas (non tous, mais prèsque), une des solutions s'impose ;
l'autre, c'est plutôt « on pourrait le faire s'il n'y avait pas
d'alternatif ».


Une des solutions s'impose, oui, mais l'interessant est pourquoi. Et
l'axe run-time/compile-time n'est pas toujours le plus pertinent. Il
est interessant de revoir pourquoi Cardelli n'utilise pas ce critere
dans sa classification des polymorphismes.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org





Avatar
James Kanze
Ivan Vecerina wrote:
"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.


Dans la mésure que les réponses sont celles qu'il voulait
entendre, parce que sinon...

Ou est-ce que tu as simplement oublié l'émoticon, et c'est un
essai à l'ironie ?

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 :




Mais évidemment, Olivier n'a jamais dit qu'une telle chose était
impossible. Seulement, il y a bien peu d'applications réelles où
c'est le cas. (Même dans nos applications de marché, qui sont
des bêtes de calcul numérique, les fonctions virtuelles ne
posent pas de problème.)

....


Dans les applis que je connais, les bottlenecks il faut les
chercher dans les allocations dans le tas,



Dans les applications que j'ai vu, le goulot a prèsque toujours
été l'écriture disque. Une écriture disque, c'est 10
millisecondes, incomprimable. Avec les processeurs modernes, 10
millisecondes CPU, c'est une éternité.

Pour la reste, il y en a encore un qui n'a pas compris ton
propos. Comment on optimise, on le sait. La question était bien,
qu'est-ce qu'il faut optimiser. (Et oui, ça m'est arrivé aussi
une fois que le goulot était bien les allocations mémoire. Et la
solution était de allouer moins souvent, non d'optimiser des
allocations pour un type particuler.)

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34



Avatar
James Kanze
Gabriel Dos Reis wrote:
Olivier Azeau writes:


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


très certainement.


[...]

je ne nie pas ce que tu affirmes connaître. Je te fais juste
remarque ue la communauté C++ est très diverse et variée. Ses
utilisations aussi. Comme BS dirait « I don't know what C++
programmers do. » Je ne sais pas non plus, mais je peux
certainement reconnaître des affirmations basées sur des faits
très limités.


Et pourquoi est-ce que tu ne l'as pas dis comme ça d'abord ?

Personne ici, j'espère, prétend avoir tout vu de ce qu'on peut
faire en C++. Olivier n'a pas dit que ça n'arrive jamais. Il a
dit que ça n'était pas le cas dans ces applications. Et moi, je
pourrais confirmer que son expérience n'est pas unique à cet
égard. Et en dehors du calcul numérique (qui est un domaine
assez particulier, à plusieurs égards), je vois mal un cas où ce
serait le cas.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Avatar
Olivier Azeau
Ivan Vecerina wrote:
"Olivier Azeau" wrote in
message news:1ldMd.19835$
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.


Il y a quand même un monde entre écrire des classes templates et en
prendre des toutes prêtes, non ?
N'importe quel habitué du C qui n'a jamais vu une classe va arriver à
faire quelque chose avec un std::vector<std::string> et peut être même
avec ce drôle de truc que renvoie la fonction begin() et qui ressemble à
un pointeur sur le premier élément du tableau.


2 3 4 5 6