Discussion :

[pseudocode]

Et en quoi il y a moins de boulot, entre implémenter une interface en Java, et implémenter une classe abstraite (équivalent d'une interface) en C/C++? Parce que là, soit j'ai loupé un truc, soit on parle pas de la même chose...

c'est juste qu'en java, l'interface "Serialize" est vide. Il suffit juste de mettre "implements Serializable" au bout d'une declaration de classe, et java s'occupe du reste.

[super_navide]

Et en quoi il y a moins de boulot, entre implémenter une interface en Java, et implémenter une classe abstraite (équivalent d'une interface) en C/C++? Parce que là, soit j'ai loupé un truc, soit on parle pas de la même chose...

ben si avec Boost il faut creer une méthode pour encoder/decoder chaque champ dans l'archive

en Java il n'y a aucune méthode a implémenter et un champ qui doit ne pas être encoder/decoder doit être déclarer transient

Donc tu a un temps de développement suplémentaire de développement

[Luc Hermitte]

Arg. On s'absente une demi-journé, et voilà 5 pages de plus.

(je confirme que d'avoir des citations citées qui disparaissent est super pénible!)

C++ est une couche objet au dessus de C, que ce soit au niveau syntaxe, compilation et run-time.

que nenni. Le C++ n'est plus le C with classes depuis bien longtemps

Bah voyons... c'est clair que le C et le C++ n'ont rien a voir...

[et plus loin tu disais que le C++ n'était pas OO, mais multiparadigme...]
Bon, il est vraiment nécessaire de perdre du temps là dessus ? "Le C++ est une sur-couche plein de choses au dessus du C, pas juste objet!"
Nous sommes d'accord maintenant ?
(Si j'ai réagis, c'est à cause de critiques/avis/rumeurs/... que j'avais pu lire ici qui démontraient un parfaite méconnaissance du C++ au délà du C with classes)

Les performances du C++ sont donc voisines de celles du C. Il y a un tres leger ralentissemnt dû a la run-time engine du C++ qui gere les objets (
b- new/delete,
c- appel de methode,
d- overiding ).

b- new appelle, en plus, un constructeur pour les objets. C'est une opération nécessaire guère différente d'un malloc + init

c- Je suppose que tu fais référence aux fonctions membre non virtuelles (vu le d-) => Tout faux. this est un argument nécessaire que l'on retrouve en C quand on doit appeller une fonction sur une structure.

d- Arg, le coût révé des fonctions virtuelles. C'est un faux problème. Une fonction virtuelle est un moyen de réaliser un branchement en fonction d'un type de donnée ; ce n'est pas une boucle d'oreille que l'on met pour faire beau. Si tu dois évaluer ce coût, alors compare-le à celui d'une série de if, à celui d'un switch, ou à celui d'un appel via d'une table d'indirection. Cela n'a pas de sens de critiquer ce coût hors contexte des problèmes que cette fonctionnalité solutionne.

Tu essayes de me convaincre qu'il n'y a pas de runtime engine en C++ ? Dans ce cas, il faudra me montrer le code de la libraire où sont implémentés new/delete, try/catch/exception, dynamic_cast et m'expliquer qui appelle le constructeur des objets globaux....

(Passons pour le run-time engine, des instructions qui font des choses bien précises dans le process courant, cela ne s'appelle pas comme celà -- je soupçonne que tu fais en fait référence au modèle objet du C++.)

Re-regardes où j'ai mis mes "b-", "c-" et "d-".
Là où je te contredis, c'est dans les coûts que tu affirmes "nouveaux" (i.e. "propres au modèle objet du C++")

b- un appel à new sur des ints pourras être plus lent ou plus rapide que l'appel à malloc -- C'est un chouilla différent, mais similaire. Sur des objets (pour revenir au contexte de ton affirmation initiale -- int n'étant pas un objet), une opération supplémentaire est nécessaire. Et elle ne coute rien de plus que ce qui est nécessaire : l'appel à un constructeur. Cela avait été une fonction init() que cela n'aurait rien changé par rapport au C.

c- Fais une fonction C qui reçoit une structure en paramètre, et une fonction membre. Maitenant, fais un bench, et trouve une différence dans le coût de l'appel. De nouveau, le modèle objet du C++ n'introduit aucun surcoût superflu. Besoin d'un paramètre vers un aggrégat d'attributs ? Très bien, on empile implicitement un pointeur this. 0 différence avec la réalisation d'une chose similaire en C.

d- Pareil que c- . Compare avec ce que tu aurais fais en C pour obtenir les mêmes comportements que ce que les fonctions virtuelles offrent. Au final, on ne paye rien de vraiment différent que ce que l'on aurait payé avec une autre solution -- voire on paye moins si on compare à la solution des 15 if imbriqués.


Par contre, cette fois, tu parles de choses qui sont elles différentes. Là d'accord.
Le RTTI parasite tous nos objets polymorphes.
<mode Jean-marc (aka "baton pour se faire battre")>
Tu aurais pu aussi évoquer le stack-unwinding qui est propre au modèle objet C++ -- Java n'offre pas ce genre de déterminisme -- où tous les objets automatiques sont détruits à la sortie de leur portée.
</>
NB: cf le n1666 et ses mises à jour pour avoir une idée précise et ... non imaginaire de ce que coutent les nouveautés du C++ -- B.Stroustrup en parlait dans l'article que j'avais évoqué il y a une 10aines de pages maintenant.

La seule personne que je connais et dont j'ai confiance en la capacite de commenter sur le sujet de R pour les deux langages est nettement en faveur du C++ par rapport au Java qu'il a pratique.

James ?


Plusieurs fois je vous vois parler de l'utilisation de la réflexité en I.A. Comme ça, j'ai du mal à en voir l'intérêt (abus d'I.A. "numérique"). Vous avez des références d'articles sur le sujet?

Il n'y aurais pas d'outils en Java capable d'analyser les allocations memoire faites par un programme? Je ne le crois pas.

Mes collègues au boulot utilisent jprobe.

en C++

exist-il un moyen aussi facile qu'en java ( c'est a dire implémenté l'interface Serializable ) pour pouvoir serializer un objet ??????

boost.serialize qui marche aussi sur les types natifs. Par contre, c'est résolu statiquement à la compilation (+ autre désavantage que tu as déjà cité ; je n'utilise pas Qt, mais je ne serais pas surpris qu'ils aient quelque chose avec leurs macros pour "corriger" le problème que tu constates)

ben si avec Boost il faut creer une méthode pour encoder/decoder chaque champ dans l'archive

[...]
Donc tu a un temps de développement suplémentaire de développement

Certes. Mais rien qu'un bon éditeur de texte pluginisable couplé à ctags ne permette d'automatiser.

[Jean-Marc.Bourguet]

(je confirme que d'avoir des citations citées qui disparaissent est super pénible!)

+1

James ?

Gagné.

Mes collègues au boulot utilisent jprobe.

L'absence d'outils m'étonnait vraiment.

[nicØB]

J'en profite pour poser quelques questions (je m'en fou un peu de savoir qui est 10% plus rapide que l'autre, je trouve juste le C++ trop long à apprendre pour une utilisation personnelle et c'est également plus long de faire un prog qu'avec Java).

En C++, est-ce qu'il est possible de compiler du code dynamiquement ? Je ne sais pas si ceux sont les bons termes, disons qu'en Java il est possible de créer une nouvelle classe une fois le programme lancé (à l'aide d'ASM). C'est également possible de modifier une classe de son propre programme.

En C++, est-ce qu'il est ainsi possible de plugger du code pendant que le programme fonctionne ? Par exemple en Java il est possible d'ajouter le service de management alors que le programme est déjà lancé.


Enfin, quelqu'un faisait plus ou moins le reproche qu'il n'y ait pas d'héritage multiple de classes. Quel est l'intérêt ? En OO quand on hérite d'une classe, c'est pour faire de la spécialisation, alors pourquoi hériter de plusieurs classes ?


P.S: le débat tourne à la comparaison C++ (utilisé par un développeur de bon niveau) vs Java (utilisé par un newbie)...

[Kujara]

J'en profite pour poser quelques questions (je m'en fou un peu de savoir qui est 10% plus rapide que l'autre, je trouve juste le C++ trop long à apprendre pour une utilisation personnelle et c'est également plus long de faire un prog qu'avec Java).

En C++, est-ce qu'il est possible de compiler du code dynamiquement ? Je ne sais pas si ceux sont les bons termes, disons qu'en Java il est possible de créer une nouvelle classe une fois le programme lancé (à l'aide d'ASM). C'est également possible de modifier une classe de son propre programme.

Le programme c++, une fois compilé, ne peut etre changé.
A part injection de code via buffer overflow, bien sur.

En C++, est-ce qu'il est ainsi possible de plugger du code pendant que le programme fonctionne ? Par exemple en Java il est possible d'ajouter le service de management alors que le programme est déjà lancé.

Possible : chargement dynamique de DLL; recuperation dynamique de pointeurs de fonctions de cette dll.

P.S: le débat tourne à la comparaison C++ (utilisé par un développeur de bon niveau) vs Java (utilisé par un newbie)...

Ce débat etait ridicule depuis le debut
Néanmoins, j'y ai appris quelques petits trucs, donc ce n'est pas une perte *totale* de temps

[millie]

Possible : chargement dynamique de DLL; recuperation dynamique de pointeurs de fonctions de cette dll.

Sous Unix, il y a les appels système dlopen et dlsym pour ça

[nicØB]

Ok merci.

Le programme c++, une fois compilé, ne peut etre changé.

Domage c'est parfois utile.

Par exemple la lib Terracotta, qui permet de faire du clustering sans qu'on ait à utiliser une API quelconque, modifie les classes d'un programme pour injecter du bytecode, par exemple pour savoir quand un objet est modifié et ainsi le synchroniser entre les serveurs.

Mais peut être qu'il y a d'autres façon de faire en C/C++.

[pseudocode]

Arg. On s'absente une demi-journé, et voilà 5 pages de plus.

La taverne n'a qu'a bien se tenir...

[et plus loin tu disais que le C++ n'était pas OO, mais multiparadigme...]
Bon, il est vraiment nécessaire de perdre du temps là dessus ? "Le C++ est une sur-couche plein de choses au dessus du C, pas juste objet!"
Nous sommes d'accord maintenant ?

Non, bien sur ce n'est pas "juste" une couche OO au dessus du C. En fait, j'aurais du dire: "le C++ a une couche OO que le C n'a pas". mea culpa.

(Passons pour le run-time engine, des instructions qui font des choses bien précises dans le process courant, cela ne s'appelle pas comme celà -- je soupçonne que tu fais en fait référence au modèle objet du C++.)

Désolé si la terminologie n'est pas bonne. J'ai proposé d'employer le terme "runtime environment" au lieu de "engine" qui, c'est vrai, a un petit gout d'inversion de controle qui n'a pas de raison d'etre.

b- un appel à new sur des ints pourras être plus lent ou plus rapide que l'appel à malloc -- C'est un chouilla différent, mais similaire. Sur des objets (pour revenir au contexte de ton affirmation initiale -- int n'étant pas un objet), une opération supplémentaire est nécessaire. Et elle ne coute rien de plus que ce qui est nécessaire : l'appel à un constructeur. Cela avait été une fonction init() que cela n'aurait rien changé par rapport au C.

Effectivement, ca ne change rien si tu rajoutes dans ton programme C tout ce que fait le C++... Mais generalement, quand tu fais du C, tu ne recréés pas une couche "object-like" au dessus des structures de données de base (struct,union,...). Ou alors, autant carrement prendre le C++.

c- Fais une fonction C qui reçoit une structure en paramètre, et une fonction membre. Maitenant, fais un bench, et trouve une différence dans le coût de l'appel.

Hum... je doute que, lors d'un overriding, le C++ puisse résoudre les appels au moment de la compilation. Mais peut-etre me trompe-je ?

d- Pareil que c- . Compare avec ce que tu aurais fais en C pour obtenir les mêmes comportements que ce que les fonctions virtuelles offrent. Au final, on ne paye rien de vraiment différent que ce que l'on aurait payé avec une autre solution -- voire on paye moins si on compare à la solution des 15 if imbriqués.

Yes, tout a fait d'accord. Idem "b", si c'est pour réecrire en C ce que fait nativement les C++, ca n'a aucun interet.

En C++, est-ce qu'il est possible de compiler du code dynamiquement ? Je ne sais pas si ceux sont les bons termes, disons qu'en Java il est possible de créer une nouvelle classe une fois le programme lancé (à l'aide d'ASM). C'est également possible de modifier une classe de son propre programme.

Il y a plusiseurs moyen, en C++ comme en Java:
- Appeler le compilateur (gcc/javac) puis charger dynamiquement le resultat (.dll/.class)
- Utiliser un interpreteur, par exemple d'un langage dynamique (python/groovy)

Il est vrai que, dans ce cas, c'est plus simple en Java qui propose ces 2 moyens via les API de base. En C++, il faut mettre un peu les mains dans le cambouis mais ca se fait. Par exemple, j'ai déja integré un interpreteur python et php dans un programme C++. Par contre j'ai jamais essayé de compiler dynamiquement une dll avec gcc puis de la charger, mais je crois me souvenir d'un truc sur codeproject qui fait ca.

[Jean-Marc.Bourguet]

Mais generalement, quand tu fais du C, tu ne recréés pas une couche "object-like" au dessus des structures de données de base (struct,union,...).

Ca se fait plus que tu ne le penses.
http://ldeniau.web.cern.ch/ldeniau/oopc.html

c- Fais une fonction C qui reçoit une structure en paramètre, et une fonction membre. Maitenant, fais un bench, et trouve une différence dans le coût de l'appel.

je doute que, lors d'un overriding, le C++ puisse résoudre les appels au moment de la compilation. Mais peut-etre me trompe-je ?

1/ Le point était qu'il faut comparer ce qui est comparable. S'il y a overriding, il faut comparer avec quelque chose ayant le même effet en C.
2/ Dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct mere { virtual void f(); };
struct fille: mere { void f(); }:
int main() {
   fille v;
   v.f();
}

il n'y a aucune raison de ne pas résoudre l'appel statiquement (petite vérification, c'est bien ce que fait g++ même sans optimisation).

En C++, est-ce qu'il est possible de compiler du code dynamiquement ? Je ne sais pas si ceux sont les bons termes, disons qu'en Java il est possible de créer une nouvelle classe une fois le programme lancé (à l'aide d'ASM). C'est également possible de modifier une classe de son propre programme.

Il y a plusiseurs moyen, en C++ comme en Java:
- Appeler le compilateur (gcc/javac) puis charger dynamiquement le resultat (.dll/.class)
- Utiliser un interpreteur, par exemple d'un langage dynamique (python/groovy)

Il ne faut pas oublier comme exemple de programme C++ qui utilisent cette dernière possibilité tous ceux qui utilisent comme interpréteur une JVM... y compris ceux dont l'exécution de la JVM est le seul objectif

Il y a une troisième possibilité: généré du code natif et l'exécuter. Voir gnu lightening par exemple de bibliothèque de ce genre.

[pseudocode]

Ca se fait plus que tu ne le penses.
http://ldeniau.web.cern.ch/ldeniau/oopc.html

. Y a vraiment des gens pret a tout pour pas utiliser C++.

Il ne faut pas oublier comme exemple de programme C++ qui utilisent cette dernière possibilité tous ceux qui utilisent comme interpréteur une JVM... y compris ceux dont l'exécution de la JVM est le seul objectif

Les Javaistes sont des Cplusplusien qui s'ignorent.

Il y a une troisième possibilité: généré du code natif et l'exécuter. Voir gnu lightening par exemple de bibliothèque de ce genre.

oui, c'est l'equivalent de la librairie "ASM" dont parlait nicØB. Mais je trouve ca un peu extreme comme solution.

[koala01]

(snip)

Hum... je doute que, lors d'un overriding, le C++ puisse résoudre les appels au moment de la compilation. Mais peut-etre me trompe-je ?
(snip)

C'est fait systématiquement lorsque l'on utilise les template, par exemple (la méta programmation de manière générale)

[Luc Hermitte]

(Ah ... moins d'une page. Aujourd'hui, vous avez été sages, c'est bien)

@nicØB. Oui c'est possible en utilisant ce que nous offre notre système -- corrolaire, ces possibilités explicitées ne sont pas dans le standard du C++. Plusieurs ont déjà précisé comment ; note dans le cas de compiler une bibliothèque dynamique pour la charger, il faut déjà savoir ce que l'on va bien pouvoir charger dynamiquement de la sorte (i.e.: il est nécessaire d'avoir un protocole pour communiquer avec ce qui est chargé dynamiquement). Et encore, avec un petit coup de demangle sur les bibliothèques dynamiques, il y a moyen de charger des trucs dont on ne connait pas vraiment les signatures. (une proto réflexivité dynamique en somme)

De plus, il existe un interpréteur C++ (je n'en connais pas deux).

Concernant l'héritage multiple, cela permet de faire un truc génial que le Java ne permet pas nativement (toi tu n'as pas lu l'intégralité des 50 pages du débat! ) (il faut faire appel à des préprocesseurs externes) : l'héritage multiple de contrat, contrat à prendre dans le sens "programmation par contrat". (L'un des points qui est source de la faiblesse côté 'R' chez le Java)


@ pseudocode. La réponse de Jean-Marc explicite mes sous-entendus : il faut comparer à "iso-fonctionnalité" (terme mal choisi, désolé). Une fonction membre (non virtuelle) va se comparer à une fonction qui prend la structure en paramètre. Une fonction membre virtuelle va se comparer à un branchement dynamique. On me met pas toutes les fonctions en virtuel, c'est ridicule (soyez sympas, faites une recherche avancée : avec mon crash de disque j'ai paumé tous mes liens anti-radotage)

@ koala, dans le cas de la spécialisation template, on ne parle pas officiellement d'overriding.

[koala01]

@ koala, dans le cas de la spécialisation template, on ne parle pas officiellement d'overriding.

Ah au temps pour moi, et, juste pour info, de quoi parle-t-on "officiellement"

[Luc Hermitte]

Spécialisation et surcharge ? (ce qui correspond à ce qui est exactement réalisé ; je n'ai pas l'impression qu'il y a un terme général qui englobe ces deux techniques de spécialisation)

[nicØB]

Merci pour les infos Luc Hermitte.

Concernant l'héritage multiple, cela permet de faire un truc génial que le Java ne permet pas nativement [...] : l'héritage multiple de contrat, contrat à prendre dans le sens "programmation par contrat".

En java on peut très bien faire de la programmation par contrat via les interfaces.
J'ai du louper un truc.

[pseudocode]

(Ah ... moins d'une page. Aujourd'hui, vous avez été sages, c'est bien)

a force, on finit par s'essouffler.

De plus, il existe un interpréteur C++ (je n'en connais pas deux).

A part CINT, je n'en connais pas d'autre non plus ?

Concernant l'héritage multiple, cela permet de faire un truc génial que le Java ne permet pas nativement (toi tu n'as pas lu l'intégralité des 50 pages du débat! ) (il faut faire appel à des préprocesseurs externes) : l'héritage multiple de contrat, contrat à prendre dans le sens "programmation par contrat". (L'un des points qui est source de la faiblesse côté 'R' chez le Java)

Hum... L'héritage multiple est une fonctionnalité "technique" très puissante, par contre en terme de "design" c'est souvent mal employé. Effectivement, dans le cas de programmation par contrat, c'est utile (encore qu'avec l'implementation multiple d'interfaces et le DP décorateur on s'en passe très bien en Java )

Les "nouveaux" développeurs en objet on tendance a utiliser l'héritage comme un moyen de factoriser leur code. Du genre, si une même méthode apparaît dans 2 classes, on créé une classe de base avec la méthode en question et on utilise l'héritage pour ne pas la recoder . Bref, une violation de plusieurs règles de COO d'un seul coup.

Et pour le coup, ce genre de violation est plus facilement décelable a la lecture d'un code Java (avec son héritage simple) qu'avec le C++. C'est très rare d'avoir a utiliser l'héritage en Java (et même en OO). En fait, a part la spécialisation d'un comportement, il n'y a pas de raison de l'utiliser.

De ce fait, dés que je vois le mot clé "extends" en Java, je passe en mode "revue de design". Et il y a 9 chance sur 10 pour qu'il y ait une violation du principe de de substitution de Liskov.

En C++, j'ai plus de mal a déceler les violations de ce genre car l"héritage est la norme. Que ce soit l'implementation d'un contrat, de la spécialisation ou de la factorisation, tout passe par l'héritage. Je trouve que les revues de design a partir du code sont plus complexe en C++

@ pseudocode. La réponse de Jean-Marc explicite mes sous-entendus : il faut comparer à "iso-fonctionnalité" (terme mal choisi, désolé).

Arf. Comme dit xololol, les langages ont chacun leur domaine d'application. Rajouter des fonctionnalités "object-like" au C, tout ça pour le comparer au C++ n'a pas beaucoup d'intérêt. Ça serait comme rajouter une VM au C++ pour le comparer a Java.

[toomytooms]

Eh bien en fait je désire connaître (un bien grand mot, disons plutôt apprendre ) les deux.

Et c'est justement la question que je me pose de savoir dans quel cas il est plus judicieux d'utiliser l'un plutôt que l'autre. J'ai bien compris en ce qui concerne la rapidité d'exécution et la portabilité mais quels sont les autres critères de choix en fonction de quel genre d'application ?

Coucou,
en gros le C++ est un langage à 99, 99% objet qui reprend la syntaxe du C.
son avantage est sa rapidité, le nombre de librairies disponible et sa portabilité (car mis à part qq trucs , si on code bien en c++ avec des libs multi plateforme, le code est portable).
son desavantage est sa complexité (gestion memoire) et sa possible future obsolescence (pitié non car je ne connais quasiment que le c/c++) face au C# ou au Java.
Le java est 100% portable mais un peu lent donc à déconseiller pour des appli 3D ou de traitement vidéo / son /image ou les calculs doivent être rapide.
A bientot

[koala01]

(snip)
son desavantage est sa complexité (gestion memoire) et sa possible future obsolescence (pitié non car je ne connais quasiment que le c/c++) face au C# ou au Java.(snip)

Sur ce point, on peut te rassurer...

Si même C et C++ *peuvent* (éventuellement) être considérés comme "obsolètes" dans un futur indéterminé, il n'en reste pas moins que, comme tout langage qui a été utilisé pendant plusieurs décennies, ils resteront utilisés, ne serait-ce que dans certains secteurs réellement particuliers...

Quelques exemples "choisi":

-Ada est encore utilisé dans le programme "Ariane"
-COBOL est encore utilisé dans les domaines des assurances et des banques
-Fortran est encore régulièrement utilisé pour les applications de mathématiques scientifiques
...

La raison principale de ce fait est que, l'un dans l'autre, il revient "moins cher" de maintenir et d'améliorer les décennies de code déjà écrit que de devoir... prévoir leur remplacement dans d'autres langages.

De plus, certains langages sont particulièrement puissants dans certains secteurs bien particulier (sauf erreur, C et C++ n'arrivent aux performances de COBOL pour la gestion de gros fichier).

De ce fait, s'il faut prévoir le temps nécessaire pour remplacer le code pour obtenir au final quelque chose qui travaillera en une fois et demie ou deux fois plus de temps (ou peut être plus), la question de savoir s'il faut effectuer la transition est... vite réglée

[Luc Hermitte]

En java on peut très bien faire de la programmation par contrat via les interfaces.
J'ai du louper un truc.

Oui. Comment tu spécifies tes pré- et post-conditions, ainsi que tes invariants dans une interface ? (sans passer par un outil pré-processant ta javadoc)
Le C++ le permet nativement en héritant multiplement de classes abstraites, qui elles enforcent les contrats en vérifiant tout cela. Cela demande certes de l'huile de coude (comparé à Eiffel ou D), mais c'est supporté nativement.

Hum... L'héritage multiple est une fonctionnalité "technique" très puissante, par contre en terme de "design" c'est souvent mal employé.

Tu es gentil. Je dirai même que c'est l'héritage qui est carrément utilisé à tords et à travers, sans aucune compréhension/prise en compte du LSP. Comment veux-tu avec ça que l'héritage multiple soit bien employé par les hordes d'informaticiens à qui on a vendu que l'héritage servait à réutiliser du code ? (!= de "se faire utiliser en place de")

Effectivement, dans le cas de programmation par contrat, c'est utile (encore qu'avec l'implementation multiple d'interfaces et le DP décorateur on s'en passe très bien en Java

Hum ... Permets-moi d'être circonspect. Je vois quantité de problèmes. Que le code client implémente de l'interface, et il n'y a aucun moyen de vérifier automatiquement (dans le code client) que les contrats des opérations de l'interface seront bien respectés si le client n'encapsule pas son objet dans le décorateur qui va bien.

Arf. Rajouter des fonctionnalités "object-like" au C, tout ça pour le comparer au C++ n'a pas beaucoup d'intérêt. Ça serait comme rajouter une VM au C++ pour le comparer a Java.

Je ne suis pas sûr que tu aies saisi ce que j'essaie d'exprimer (maladroitement) depuis 3 posts.
Quand je parle d'iso-fonctionnalité, je parle de solutionner un même problème:
- appliquer une opération sur une donnée (quelle soit une aggrégation ou non)
- décider, à l'exécution, du traitement à exécuter en fonction d'un état
- ...
Quelque soit le langage, ces problèmes peuvent être résolus d'une ou plusieurs façons différentes. Ces besoins existent de manière complètement indépendante de l'OO. L'OO apporte juste de nouvelles façons de les solutionner. Si on doit évaluer les nouveaux apports OO du C++, c'est relativement aux problèmes qu'ils solutionnent. Pas par rapport à des éléments syntaxiques prochent qui ne solutionnent pas les mêmes problèmes.