Discussion :

[Matthieu Vergne]

Donc c'est ce fameux duck typing qui fait la différence ici. Sans ça, ce qu'il serait possible de faire avec de telles structures se fait déjà. Donc en un sens c'est effectivement un problème qui n'existe pas en Java, parce qu'avant d'avoir de tels problèmes il faudrait avoir le duck typing, ce qui est un autre problème pas encore réglé lui par contre {^_^}.

Et donc oui j'aimerais bien avoir du duck typing en Java (ou la possibilité de définir des équivalences autrement).

[SKone]

Avec LVVM c'est de moins en moins vrai.

Et parce qu'ils ont de vrais avantages et le C++ de vrais défauts.
Je veux bien reconnaître l'importance de la maturité mais pas te regarder affirmer qu'ils sont simplement "cool" parce que djeuns'.

LLVM c'est bien seulement si la toolchain du début a la fin est valide. En ce qui concerne les plateformes spécifiques même si LLVM permet de produire du C++, pas dit à 100% que le C++ généré sera compatible avec le compilateur de la target. Mais sinon oui je vois l'idée.
Pour les autres langages oui ils ont de réel avantage je les vois. Je dis juste que ces langages ne sont pas assez mature pour qu'on puisse voir leur défaut comme on le fait aussi vite avec le C++.

Non, ça c'est faux. Du code C, oui. Mais pas du code C++

Au contraire, je dirais que c'est certainement le pire langage pour cela. Le C++ n'est supporté directement par aucun langage

Je vois ce que vous voulez dire. Mais prenez n'importe quel classe C++, on n'est tous capable de faire un void* MaClass_CreateInstance(); void MaClass_DestroyInstance( void* pInstance );. De cette manière tout passé en CCall pour les méthodes ... MaClass_MaMethode( void* pInstance, ... );
De cette manière on passe rapidement du C++ au C. Et si on a comme target un langage avec la notion de classe et la on gagne la structure de classe avec du thiscall si c'est possible, sinon toujours du CCall dans les membres.
Je pense à cette exemple parce que j'ai déjà eu à implémenter ça.

J'avais un algorithme qui devait être appelé depuis plusieurs langage/target: une DLL, du C# et un Middleware quelconque avec une autre interface. La solution a été de coder l'algo en C++ dans une classe. et l’exporter dans une DLL avec 2, 3 méthodes en CCall pour construction etc.
De cette manière je pouvais générer du code C# avec du PInvok, et générer un wrapper C et générer un wrapper Python, etc...
Si j'avais codé le tout en C j'aurais simplement perdu la "structure class" lors de l'export en C#. Dans mon cas (peut-être pas toujours pour tout le monde) cela a été le meilleurs des 2 mondes.

Pour en revenir au fil:
La question n'est même pas de comparer le C++ avec du Java. Oui y a beaucoup de chose qu'on peut faire dans les 2 langages et les 2 ont leurs "capilotractation syntaxique".
Mais les 2 langages n'ont absolument pas été designé pour les mêmes besoin. Le C++ a comme fondation "Ne pas sacrifier les performances". Mais on accepte les compromis, par exemple pour ceux qui ne sont pas content parce qu'il n'y a pas de GC, on n'ajoute pas de GC mais on met des shared_ptr, unique_ptr, etc... C'est un compromis, bien sur cela coûte plus chère, mais personne n'utilise ces trucs là dans les applications temps-réel, tout le monde code ses allocateurs mémoires en fonction des besoins.
Le Java avec le C# c'est les rois en temps de dev, si ce qui coûte le plus chère dans ton domaine d'application c'est le temps de dev et que les perfs ne sont pas critiques, soit ! Parfait utilisons du C# ou du Java.
Mais si perdre une milliseconde c'est déjà une catastrophe alors utilise du C++.

La raison pour laquelle le C++ est toujours là 35 ans plus tard c'est simplement ça:
http://benchmarksgame.alioth.debian....s-measurements
http://benchmarksgame.alioth.debian....s-measurements

Cela ne veut pas dire que le Java ou le C# est moins bon que le C++ loin de là, si on regarde les algos comparé (mandelbrot, n-body...) c'est des cas d'école.
Je doute (je peux me tromper) que le Java ou C# soit utilisé dans des applications avec des besoin en performance élevé comme les jeux vidéo, finance (HFT)...
Cela me rappel une conférence Microsoft où le speaker faisait une comparaison en du C++ et du C# dans une application de simulation de soft-body.
Et devinez quoi ? Le C# était plus performant, mais si on télécharge les sources on se rend compte que c'est une comparaison entre du C++ en Debug Mode sans SIMD VS du C# en Release Optimisé avec SIMD.

Revenons à la question du topic:
Comparons la situation avec d'autre langage, le Fortran. Aujourd'hui le Fortran est utilisé quasiment que par des scientifiques pour faire des calcules (sur du HPC entre autre). Mais pareil le monde du HPC evolue se rapproche de la programmation GPU (coder le kernel et distribué). Mais je pense que dans cette situation aussi le Fortran restera longtemps un maître même si de nombreux langage émerge. Pour les mêmes raison historique + personne d'autre a prouvé qu'il pouvait faire le travail. Et surtout parce qu'il intègre au fur et à mesure les évolutions comme OpenMP, la programmation GPU etc...

Donc si le C++ est toujours là c'est qu'on a toujours besoin de lui, tant que les applications temps réel existerons le C++ sera toujours là : pour des raisons historique et parce qu'il fait le travail et que aucun autre langage a prouvé qu'il pouvait faire se travail.

PS: Prouver qu'on peut "faire le travail" pour un langage de programmer, c'est publier un produit ou utiliser "en production" avec des performances supérieur. Parce que si les performances ne sont pas supérieur je reste dans ma base de code sur laquelle nous avons itéré pendant 10 ans.

[DonQuiche]

En ce qui concerne les plateformes spécifiques même si LLVM permet de produire du C++, pas dit à 100% que le C++ généré sera compatible avec le compilateur de la target. Mais sinon oui je vois l'idée.

Pourquoi émettre du C++ ?! Non, ils émettent du bytecode LLVM. Le fabricant du CPU fournit quant à lui un backend pour convertir ce bytecode en code machine et tous les langages utilisant LLVM compilent alors automatiquement pour cette plateforme. Y a t-il encore des fabricants qui ne fourniraient pas ce backend ? J'en doute.

Je vois ce que vous voulez dire. Mais prenez n'importe quel classe C++, on n'est tous capable de faire un void* MaClass_CreateInstance(); void MaClass_DestroyInstance( void* pInstance );. De cette manière tout passé en CCall pour les méthodes ... MaClass_MaMethode( void* pInstance, ... );

D'une part songe aux méthodes virtuelles : il faut que tu recrées manuellement la table virtuelle en créant un type (délégué) par méthode.

Pense aussi à certains scénarios de gestion de la mémoire qui obligent à faire des pieds et des mains pour épingler manuellement des tableaux imbriqués, par exemple.

Enfin le code objet encourage à passer des objets : au lieu de passer trois tableaux de floats, tu passes un tableaux de vecteurs. Autrement dit tu es en plus obligé de recréer l'implémentation interne de vecteur ! Non seulement les objets prolifèrent du fait des principes SOLID et compagnie, mais en plus tu es parfois obligé de violer l'encapsulation pour reproduire leur structure interne et non pas seulement leur API (lorsqu'ils sont passés par valeur). Ce qui fait que tu es obligé d'importer des préoccupations des programmeurs de cette biblio dans ton projet !

Pour invoquer du C++ en C#/Java, il faut vraiment n'avoir aucun choix et en être réduit à cette solution misérable. C'est moche, chronophage, source de ralentissement, source de bogues, ça oblige ton équipe à refaire une partie de la biblio importée et à se soucier de ses problématiques et de sa mise en oeuvre (implémentation).

Vraiment, hors de COM, point de salut.

Pour le reste, j'ai déjà précédemment tout dit.

[JolyLoic]

Pour invoquer du C++ en C#/Java, il faut vraiment n'avoir aucun choix et en être réduit à cette solution misérable. C'est moche, chronophage, source de ralentissement, source de bogues, ça oblige ton équipe à refaire une partie de la biblio importée et à se soucier de ses problématiques et de sa mise en oeuvre (implémentation).

Globalement d'accord avec toi sauf sur ce point. En utilisant C++/CLI, il est aisé d'appeler du C++ depuis du C#, ou du C# depuis du C++. Il faut certes toujours écrire un wrapper, mais ce wrapper s'écrit dans un langage objet, et ne demande pas trop de contorsions.

[Luc Hermitte]

Mais je pense que dans cette situation aussi le Fortran restera longtemps un maître même si de nombreux langage émerge. Pour les mêmes raison historique + personne d'autre a prouvé qu'il pouvait faire le travail. Et surtout parce qu'il intègre au fur et à mesure les évolutions comme OpenMP, la programmation GPU etc...

La force du FORTRAN réside dans le code existant et les bibliothèques fiabilisées. Côté performances, il y a un bench qui le place derrière le c++ http://economics.sas.upenn.edu/~jesu..._languages.pdf

PS: unique_ptr ne pose pas de problèmes, supplémentaires comparativement aux allocations manuelles, pour le temps-réel. Pour le TR, les allocations sont généralement interdites, et selon que l'on applique les JSF ou les CERT, il est permis d'allouer au tout début ou pas. Après, unique_ptr, c'est des garanties en plus dans au moins 4 cas d'utilisation des pointeurs (sink, source, var locale, possession massive), et ce n'est que mieux, TR ou pas.

[Uther]

Mais prenez n'importe quel classe C++, on n'est tous capable de faire un void* MaClass_CreateInstance(); void MaClass_DestroyInstance( void* pInstance );. De cette manière tout passé en CCall pour les méthodes ... MaClass_MaMethode( void* pInstance, ... );
De cette manière on passe rapidement du C++ au C. Et si on a comme target un langage avec la notion de classe et la on gagne la structure de classe avec du thiscall si c'est possible, sinon toujours du CCall dans les membres.
Je pense à cette exemple parce que j'ai déjà eu à implémenter ça.

Sauf que ton exemple marche parce qu'il porte sur un cas très simple.
Mais chaque fonctionalité de C++ complique les choses au point que ça devient vite ingérable ou très aproximatif, notament si on veut gérer le polymorphisme, la surcharge, je parle même pas des templates ...
Bref plus on utilise les fonctionnalités de C++ moins il est interopérable, c'est pour cela que c'est clairement pour moi un très mauvais choix si on vise a créer une API qui vise l'interopérabilité.

La question n'est même pas de comparer le C++ avec du Java. Oui y a beaucoup de chose qu'on peut faire dans les 2 langages et les 2 ont leurs "capilotractation syntaxique".
Mais les 2 langages n'ont absolument pas été designé pour les mêmes besoin. Le C++ a comme fondation "Ne pas sacrifier les performances". Mais on accepte les compromis, par exemple pour ceux qui ne sont pas content parce qu'il n'y a pas de GC, on n'ajoute pas de GC mais on met des shared_ptr, unique_ptr, etc... C'est un compromis, bien sur cela coûte plus chère, mais personne n'utilise ces trucs là dans les applications temps-réel, tout le monde code ses allocateurs mémoires en fonction des besoins.
Le Java avec le C# c'est les rois en temps de dev, si ce qui coûte le plus chère dans ton domaine d'application c'est le temps de dev et que les perfs ne sont pas critiques, soit ! Parfait utilisons du C# ou du Java.

Si on vise les performance brutes, C/C++ et Java/C# ne jouent en effet pas dans la même cour. Les deux premiers sont des langages "système", compilés avec un accès direct a la mémoire et au système, alors que les seconds sont des langages uniquement haut-niveau qui tournent sur une VM.

Ceci dit dans le domaine des langage système le C++ peux être comparé à d'autre langages comme D, Ada ou Rust, ...

[SKone]

Pourquoi émettre du C++ ?! Non, ils émettent du bytecode LLVM. Le fabricant du CPU fournit quant à lui un backend pour convertir ce bytecode en code machine et tous les langages utilisant LLVM compilent alors automatiquement pour cette plateforme. Y a t-il encore des fabricants qui ne fourniraient pas ce backend ? J'en doute.

Je connais ce genre de fabriquant et je travail avec eux

Pour le reste des problèmes tout se résout avec de la génération de code. Tu parses et tu génères on est tous capable de faire ça. C'est la solution qui a été choisit dans mon cas.
VTable, template, polymorphisme, type etc ça passe. Certe on perd l'inlining mais à ce niveau pas le choix.

Sur le jugement de valeur avec du "misérabiliste de ce choix", si je donne plus de détail peut être changeriez vous d'avis. Et bien pour être plus précis on a un process qui est assez lourd qui doit être résolut le plus rapidement possible (il y a du calcule assez lourd sur CPU et GPU). Ca doit etre appelé depuis une interface C# et du MaxScript (langage de scripting 3DSMax) et ZBrush Script (script du logiciel ZBrush) et aussi depuis un editeur en C#.
Donc plusieurs data structure mais toutes peuvent être récupéré via du Marshalling (C#) ou par pointeur et là un simple memcpy depuis un pointeur de float ou double.
Si vous avez une meilleurs solution je prend.
Comme le code est parser généré ce n'est pas time consuming, juste à coder la partie C++ et tout le reste suit. Pour l'équipe c'est transparent, les artistes font leur MaxScript, ZBrushScript, leur Script C# et les programmeurs UI font leur interface comme d'habitude. On envoi une data-structure comme d'habitude et le marshaling etc est fait automatiquement.
Le seul cout a été la mise en oeuvre du système.

La force du FORTRAN réside dans le code existant et les bibliothèques fiabilisées. Côté performances, il y a un bench qui le place derrière le c++ http://economics.sas.upenn.edu/~jesu..._languages.pdf

PS: unique_ptr ne pose pas de problèmes, supplémentaires comparativement aux allocations manuelles, pour le temps-réel. Pour le TR, les allocations sont généralement interdites, et selon que l'on applique les JSF ou les CERT, il est permis d'allouer au tout début ou pas. Après, unique_ptr, c'est des garanties en plus dans au moins 4 cas d'utilisation des pointeurs (sink, source, var locale, possession massive), et ce n'est que mieux, TR ou pas.

Oui je suis d'accord. Même s'il y a pas mal d'initiative qui ont été fait pour essayé de se défaire de ces API Fortran. J'ai déjà eu a méler du Fortran issu de gcc avec du VC++. Et bien GCC le fait exprès, pour ne pas faciliter le travail.

Sinon pour l'allocation c'est une stratégie comme une autre. On peut aussi alloué au début du programme Plusieurs page et quand on demande a notre Custom allocator N Bytes ou lui donne un pointeur vers là où c'est disponible, par contre il faut faire attention à la defragmentation etc.

Bref.

[r0d]

Personnellement, une question me tarabuste en ce moment. Une des raisons du succès de c++, et c'est un argument avancé dans le PO, c'est qu'il est très bien adapté pour le développement de très grosses applications. Or, j'ai l'impression que la tendance va de plus en plus dans le sens de petites applications qui communiquent entre elles (grid, cloud, etc.).

Le c++ est mon langage préféré, mais j'avoue que je connais trop peu les autres langages pour être en mesure de proposer une comparaison pertinente. Par exemple, j'apprécie beaucoup java (et je l'utilise beaucoup en ce moment), mais je ne connais pas assez en profondeur ce langage pour pouvoir donner des raisons objectives pour lesquelles je préfère le c++, et j'ai plus l'impression que ma préférence est d'ordre grégaire (l'habitude, et donc le confort, d'un langage que je maitrise).

Quelques exemples:
- Il y a 5 ans, Firefox (le noyau) c'était XUL et c++. Maintenant il y a aussi du javascript natif et du XBL.
- De plus en plus de langages de script interfacent directement CUDA (python, lua, ...).
- HTML 5 qui peut taper directement dans les drivers OpenGL.
- JNode qui permet d'attaquer directement les pilotes du hardware.
- Les applications internes sont de plus en plus modulaires (l'exemple type: un démon en C qui récolte des données et les range dans une base de donnée, puis tout un tas d'applications "sexy" et jetables, développées en divers langages en fonction des besoins, pour y accéder et les modifier).

J'ai donc un peu peur, à long terme, pour mon langage préféré, qui est particulièrement adapté pour des grosses applications à durée de vie très longue, parce que j'ai l'impression que ce mode de conception est voué à disparaitre. J'espère que je me trompe.

[Matthieu Vergne]

Non tu ne te trompes pas je pense. Je raccourci, mais l'idée principale est là :

La grosse appli monolitique on a bien compris que c'est pas facilement maintenable : tant que tu gardes ton expert en la matière, tu es sûr d'avoir une formule 1, mais dès que ton expert te quitte... tu l'as profond, parce que former quelqu'un sur une appli complète ça prend des années et à condition que l'expert en question soit un bon prof (avis perso : ce qui est rarement le cas). Le fait de faire du modulaire permet de séparer les responsabilités et expertises, chacun travaillant sur son petit bout de code. Et si y'en a 1 qui s'en va, tu n'as à former que pour ce petit bout de code et ceux qui sont encore là peuvent aider. De même, si vraiment c'est irreprenable, ben c'est qu'une petite partie à refaire et non l'ensemble.

Par la suite, le fait de faire du modulaire permet de spécialiser davantage les langages : plutôt que de dépendre d'un seul langage touche à tout, pour un module spécifique un langage donné peut être plus intéressant (plus facile à coder, plus riche sur le domaine considéré, etc.), on peut donc profiter de l'indépendance du module pour changer de langage sur ce module en particulier et faire une interface qui va bien pour raccrocher au reste. Bien entendu, le langage qui va bien ce n'est pas uniquement du fait de ses possibilités, mais aussi du développeur à charge. S'il est compétent en X mais n'y connais rien en Y, ce sera surement du X, même si Y a généralement plus la côte pour les fonctionnalités recherchées. On fait toujours avec ce qu'on a sous la main, compétitivité oblige.

Du coup, avec des applis toujours plus riches et plus complexes, tu vois vite où va la tendance. Langages multiples, plateformes multiples, etc. Et avec des trucs comme les services, le cloud, l'internet des objets, etc. on modularise et délègue toujours plus. Cela dit, ne soit pas effrayé : ça s'applique sur des équipes, pas les développeurs eux-même. Le développeur on lui demande pas (en général, mais ça dépend où tu tombes) de tout faire sur 10 langages différents au lieu de 2. Sur la partie qu'il a à charge, il peut rester avec son langage de prédilection + les à côtés qu'il a besoin. C'est sur l'ensemble de l'équipe que tu vois la multiplication s'opérer, où plutôt que d'avoir 10 personnes bossant le même langage, tu vas en avoir 3 faisant du X, 2 sur du Y, 3 sur du Z, etc.

[foetus]

Je ne suis pas trop d'accord avec Matthieu Vergne (le post ci-dessus)

Aujourd’hui on a une banalisation de la programmation et donc la multiplication des langages et autres méthodes "Rapid Application Development"
Comme dans d'autres domaines auparavant (l'imprimerie/ l'édition ou l'habillement par exemple) on va avoir une grosse majorité qui connaitra le sujet plus ou moins bien et un noyau de professionnels/ initiés/ passionnées/... qui maintiendront "les connaissances" et les langages/ méthodes/ ... "historiques" (parce que pour l'instant on ne peut pas faire sans et ce sont des "trucs" qui ont prouvé leur efficacité).

Les avantages sont certains: toujours avoir des développeurs à porter de main et avoir une communauté pour fidéliser son logiciel/ son environnement

D'ailleurs the Difference Between A Developer, A Programmer And A Computer Scientist

[Matthieu Vergne]

Sauf que ça c'est plus en amont encore. Ce n'est pas parce que tu as plus de choix dans les langages que tu vas de facto en utiliser plus. C'est sûr que si tu en a 5 tu peux pas faire une appli avec 10 langages différent, mais le fait d'en avoir 10 te permet toujours de faire une appli sur un seul langage. Ce n'est pas vraiment ce qui te pousse à cette distribution dont r0d parle, même si ça y contribue jusqu'à un certain point.