Discussion :

[DonQuiche]

Non, pour .Net, c'est logiciel, lors de la compilation JIT: Les instructions bytecode sont de haut niveau, du genre "écrire cette variable locale", "écrire ce membre de cet objet" ou "écrire à tel emplacement de ce tableau" (avec vérification des bornes) ; et les instructions "écrire à cette adresse arbitraire" ou "appeler cette fonction non-managée" causeront une erreur de compilation JIT si le code n'est pas en Full Trust.

Ce que tu essaies d'expliquer c'est que de toute façon le code dynamique créé passe par les mêmes fourches caudines que le code initial et qu'il n'y a donc aucune raison de les traiter différemment puisque la vérification du JIT suffit offre toutes les garanties nécessaires.

Sauf que d'une part tu n'es pas à l'abri d'une défaillance du JIT ou des fonctions natives du runtime et que d'autre part MS cherche à virer le JIT. Ils sont en train de le virer sur Windows Store et ils le vireront sans doute sur Midori.

Bref, la raison pour laquelle le code dynamique est en train de disparaître sous dotnet c'est vraisemblablement d'une part à cause du DEP (tout processus est scellé sous Midori et le C++ est également interdit de code dynamique sous Windows store il me semble) et d'autre part pour ne pas avoir à charger un JIT et le bytecode des biblios.

[Battant]

Bonjour,

Je pense que l'intérêt de tel ou tel language dépends de cerain paramètre. Par exemple, nombre d'api dévoloppée pour ce language, la rapidité, l'indépendence ou non de cet api de la plate-forme comme par exemple qt ou encore les language java ou python.

Ai-je oublié des paramètres ?

Quel sont vos réactions ?

Salutations

[Matthieu Vergne]

C'est une évidence: un intérêt est toujours relatif a des préférences, qui peuvent être objectives (limites budgétaires, contraintes légales) ou subjectives (les goûts et les couleurs).

[frantzgac]

Programmer signifie concevoir et manipuler des concepts abstraits.
Soit on maîtrise les concepts qu'on utilise, soit on confie à des outils le soin de manipuler les concepts et de nous fournir un résultat.
Dans le premier cas le temps d'apprentissage est long mais la maîtrise permet d'utiliser les outils en comprenant leur fonctionnement et éventuellement en anticipant leurs faiblesses.
Dans le second cas l'apprentissage sera toujours en retard sur l'océan d'outils.
Dans un monde qui privilégie la vitesse (appelée parfois productivité) il n'est pas surprenant que la seconde solution soit populaire. D'autant plus qu'elle est très démagogique.
Mais si C++ conserve ses adeptes c'est peut être pour la même raison que COBOL. Bien des applications mille fois modifiées ne sont pas documentées et fonctionnent à peu près. Cela coûterait fort cher de les repenser et pire encore de les réécrire.
Les bons choix résultent aussi parfois de mauvaises raisons...

[Invité]

Je pense que le langage va même être encore plus populaire à l'avenir car il permet non seulement de garder des anciennes solutions qui coûteraient trop cher en production pour être remaniée, mais maintenant avec le c++ moderne le langage permet de faire des choses de manière plus rapide avec beaucoup moins de complexité. (Gestion automatique de la mémoire avec std::unique_ptr, std::shared_ptr, etc..., système de callback simple avec std::function et la méta-programmation (avec les macros pour remplacer les systèmes de réflexion et garder ainsi la rapidité du langage à l'exécution), système de sérialisation de données simple avec la combinaison de tout ça)

c++14 me permet maintenant de faire des choses très complexe de manière simple et rapide, sans pour autant nié l'apprentissage grâce aux nombreuses librairies opensource utilisant encore du c++ 98 voir même du c.

Parfois ce n'est même pas nécessaire de passé par la couche orienté objet pour les petites libs et le c++ est compatible avec un language non orienté objet. (Le C)

Ce qui est aussi un grand atout que je n'ai pas retrouvé dans d'autres language.

[the Hound]

Je pense que le langage va même être encore plus populaire à l'avenir car il permet non seulement de garder des anciennes solutions qui coûteraient trop cher en production pour être remaniée, mais maintenant avec le c++ moderne le langage permet de faire des choses de manière plus rapide avec beaucoup moins de complexité. (Gestion automatique de la mémoire avec std::unique_ptr, std::shared_ptr, etc..., système de callback simple avec std::function et la méta-programmation (avec les macros pour remplacer les systèmes de réflexion et garder ainsi la rapidité du langage à l'exécution), système de sérialisation de données simple avec la combinaison de tout ça)

Mouais ... à mon avis on ne fait que troquer des connaissances contre d'autres, et si avant tu devais apprendre comment on se sert d'un T* et comment ça marche, à présent tu dois savoir comment on se sert d'un unique_ptr et dans quels cas l'utiliser. Tu vas te préoccuper plus de la sémantique que de la mémoire, certes, mais ça ne simplifiera pas forcément le langage. Un exemple : l'ajout des références sur rvalues, qui a complexifié les notions de lvalue et rvalue, et maintenant on a xvalue, rvalue, prvalue, lvalue et glvalue ...
Quant aux évolutions du langage, c'est comme ça pour n'importe quel langage "vivant" (utilisé par une communauté conséquente et non seulement par un barbu dans sa cave), et heureusement que le langage évolue.

c++14 me permet maintenant de faire des choses très complexe de manière simple et rapide, sans pour autant nié l'apprentissage grâce aux nombreuses librairies opensource utilisant encore du c++ 98 voir même du c.Parfois ce n'est même pas nécessaire de passé par la couche orienté objet pour les petites libs

En gros t'es en train de dire que :
- on peut lire des sources en C++,
- on n'est même pas obligé d'utiliser toutes ses fonctionnalités.

Mais c'est révolutionnaire ça dis-moi

et le c++ est compatible avec un language non orienté objet. (Le C)
Ce qui est aussi un grand atout que je n'ai pas retrouvé dans d'autres language.

Ça peut être vu comme un atout ou un inconvénient.
Le fait est que la compatibilité avec C a toujours été une priorité, et cela a en réalité entravé le développement du C++.
L'agencement des structures en mémoire, la déclaration en int par défaut, ... sont des reliques du C qui n'ont que complexifié le standard et parfois même empêché d'implémenter certaines fonctionnalités (le mot-clé auto a été créé il y a plus de trente ans par Stroustrup lui-même semblerait-il, mis de côté pour une rétrocompatibilité avec C).
Donc oui, c'est bien, et c'est pas bien à la fois.

PS: je ne critique pas C++, au contraire c'est de loin mon langage préféré. Mais j'étais obligé de réagir en lisant ce post.

[Matthieu Vergne]

Grosso modo, même avis que ci-dessus.

Parfois ce n'est même pas nécessaire de passé par la couche orienté objet pour les petites libs et le c++ est compatible avec un language non orienté objet. (Le C)

Ce qui est aussi un grand atout que je n'ai pas retrouvé dans d'autres language.

Sauf que le but de l'objet c'est de faire du haut niveau. Avoir un langage qui te permet de faire les deux est plus flexible, mais en contre partie quelqu'un qui a l'habitude de faire de l'orienté objet aura du mal à prendre en main un code bas niveau, et vice-versa. La richesse d'un langage ne prend sa valeur que quand on essaye de pousser sa maîtrise jusqu'au bout, ce qui est rarement le cas en production (on peut avoir quelques héros, mais on en a rarement une équipe entière). Sans ça, ce n'est qu'offrir plus de moyens de se perdre en faisant du code hétérogène et généralement sale.

[Invité]

Il est vrai que je fais du c++ depuis plus de 5 ans et pourtant ça m'arrive encore de faire du code salle.
J'ai commencé par le c++98, j'ai juste du réapprendre le c++14 avec les rvalue et lvalue références ainsi que std::unique_ptr et std::function pour faire du code plus propre, avec l'aide de certains membre de se site c'est passé tout seul.

Donc bon oui on peut facilement faire du code salle en c++, plus facilement que dans d'autres langages comme par exemple le java et c'est pour ça qu'il ne faut pas hésiter à demander de l'aide sur les forums et à montrer son code. (Car au niveau sémentique le c++ reste quand même le language le plus compliqué que je connaisse surtout depuis l'arrivée des rvalues, lvalue, etc...)
Mais une fois que tu sais t'en servir ça devient, un énorme avantage.

[yahiko]

Même si je ne l'utilise plus depuis belle lurette parce que ce n'est pas le langage de prédilection de mon domaine, j'en garde de très bons souvenirs.
Longue vie au C++ et que se termine l'arnaque de Java.

[Matthieu Vergne]

C'est pas parce que Java ne te correspond pas qu'il ne correspond à personne.

[SKone]

Bonjour,

Pour répondre à la question, selon moi comme cela a été dit le C++ est encore là pour 2 raisons (selon moi), sa maturité et son historique.
Les nouveaux langages qui se présente comme les sauveurs (D, Haxe, Go...) même s'il propose d'importer des API C ce n'est pas suffisant.
Par exemple à titre personnel je travail dans les jeux vidéo, personne dans le jeux vidéo ne switch, ces langages n'ont pas de compilateur pour les consoles (Unity 3D triche ), de la même manière ceux qui font de l'embarqué ont besoin d'un compilateur pour target spécifique.
Et 90% des problèmes présentés ici de tel ou tel langage sont réglés par code. L'allocation, et bien en générale il faut recoder son propre allocateur en fonction de la plateforme (raison de perf, éviter la défragmentation mémoire, les jumps...), les RTTI sont utilisés seulement dans les parties haut niveau du code (gameplay) et souvent recoder on n'utilise pas le RTTI C++ natif, on choisit les classes dont sur lesquelles on accepte le RTTI...
Ces nouveaux langages sauveur ont les trouves cool seulement parce qu'ils sont jeunes et peu utilisés et la conséquence de ça ce n'est pas qu'ils n'ont aucun problème c'est juste qu'on n'a pas encore eu le temps de les trouver. Contrairement au C++ qui a des années de vie et des utilisations dans de très nombreux domaine. Finance (HFT...), Jeux Vidéo...
Donc on a pu le roder et fixer (ou contourner) de nombreux problèmes via des API interne.

Et aussi pour une raison historique, faire un moteur de jeu coute dans les 25 millions imaginer recoder ça dans un nouveau langage qui promet la lune non rodé => trop risqué...

Je pense que la raison historique est la première dans de nombreux domaine, ce qui explique la prédominance d'un langage de programmation dans certain domaine (C++, Cobol, JS, ...)
Indépendamment des compétences. Y a aussi une raison du marché du travail, exemple Facebook compile le PHP en C++ (Hip Hop). Il est plus facile de trouver un programmeur PHP (compétent) qu'un programmeur C++ (compétent).

Seulement moi le C++ devrait être le SEUL langage utilisé pour coder des API, simplement parce que c'est le seul langage qui permet d'être utilisé par tous. On peut facilement faire des API en C++ les exportés pour du C, du C# [PInvoke], du Fortran...
Le C++ est le langage pour les gouverner tous (pour les API). Tout est là, performance, portabilité... Tout est là c'est du Win/Win .
Ce qu'on ne peut pas faire avec du C par exemple parce qu'on perd directement la notion de classe, le thiscall ne suffit pas.
Bref sans troll aucun c'est juste un avis

[DonQuiche]

ces langages n'ont pas de compilateur pour les consoles

Avec LVVM c'est de moins en moins vrai.

Ces nouveaux langages sauveur ont les trouves cool seulement parce qu'ils sont jeunes et peu utilisés

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

Seulement moi le C++ devrait être le SEUL langage utilisé pour coder des API, simplement parce que c'est le seul langage qui permet d'être utilisé par tous. On peut facilement faire des API en C++ les exportés pour du C, du C# [PInvoke], du Fortran...

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

Déjà que le code C est une plaie à importer et réclame souvent une coûteuse et verbeuse gymnastique (épingler les tableaux, spécifier les offsets de chaque champ, etc), mais alors je n'imagine même pas importer du code C++, il faudrait coder des dizaines ou centaines de lignes par objet avec un type par fonction! Et je ne te parle même pas des performances désastreuses.

Ou alors il faut que ce soit du COM. Là c'est tout de suite mieux. Mais ça reste lourdingue avec des messages d'erreur parfois incompréhensibles, des problèmes de fuite mémoire à déboguer et de vieux codes d'erreur au lieu de nos exceptions. Bref, c'est lourd pour le codeur C++ et c'est lourd pour le codeur Java/C#. Et puis essaie donc d'interagir avec du code C++ depuis JS...

Enfin les API C++ sont conçues pour les objets C++. Or interagir avec vos conteneurs est une plaie sans templates. Plus généralement tous vos objets sont conçus pour le C++, tu ne peux pas prétendre que le C++ est une linga franca. Restez sur ce langage si ça vous chante mais le reste du monde a d'autres besoins et souhaite d'évoluer.

[Uther]

Seulement moi le C++ devrait être le SEUL langage utilisé pour coder des API, simplement parce que c'est le seul langage qui permet d'être utilisé par tous. On peut facilement faire des API en C++ les exportés pour du C, du C# [PInvoke], du Fortran...

Au contraire, je dirais que c'est certainement le pire langage pour cela. Le C++ n'est supporté directement par aucun langage, à part le D (qui impose quand même de très lourdes restrictions). Le C++ est bien trop complexe pour être facilement interfacable avec d'autre langage. Comme l'explique la documentation du D sur le sujet, pour s'interfacer correctement avec du C++ il faudrait que le langage réimplémente quasiment tout C++.

La seule solution pour faire du C++ interopérable consiste comme pour à peu près tous les langages de se reposer sur des wrapper en C, qui lui est une vraie lingua franca. Le problème, c'est que si on utilise réelement les capacités objet avancées de C++ ça peux très vite devenir horiblement complexe a traduire cela en C puis de les adapter aux concept équivalents du langage cible.

[Invité]

De toute façon, api moderne ou pas, tout devra passer par une couche équivalente au langage c++.

Je pense que SKone à bien résumé la situation en ce qui concerne le c++.

-Payer un (ou des) développeurs pour recoder un moteur de jeux existant du c++ vers le java, cela coûterais des millions.
-Les nouveaux langages facilitent le travail mais il est parfois nécessaire de recompiler pour des plateformes plsu exotique avec un compilateur natif en utilisant un langage de plus bas niveau.

Donc, peu importe l'api utilisée, que ça soit du java, du c#, etc..., il faudra toujours faire appel à un langage de plus bas niveau (et donc à de l'ancien car sans l'ancien, le nouveau n'existe pas), les nouveaux langages sont attirant de par leur abstraction vis à vis de certaines choses qui sont assez galère à faire en c++. (La sérialisation (surtout lorsqu'on veut un système très flexible qui supportent plusieurs formats de fichier et pas que les flux standart du langages c++), un système de réflexibilité à l'exécution avec un système de RTTI personnalisé, un système de fonctions de callback générique, etc...), il y a certaines librairies qui le font mais, ça reste quand même assez galère au niveau utilisation. (Macros, et bien souvent j'ai des crashs aussi ou bien des exceptions, bref...)

Mais finalement les langages moderne ne font pas forcément mieux malgré leur attirance de par leur simplicité d'utilisation, surtout dans le domaine des applications non gourmande au niveau des performances et de l'internet, mais au niveau optimisation, le c++ reste gagnant car :

-Il faut savoir que pour copier des listes en java ou bien des tableaux d'objets il faut utiliser arrayCopy car le java cache totalement la sémantique des objets.
-Même chose pour les types primitifs, il faut savoir qu'il faut utiliser les classes Integer, Double, etc... pour les référencer.
-Les langages modernes, n'offrent pas la possibilité de faire des templates variadiques et donc, de la génération automatique de hiérarchie et du multiple dispatch (cf : le pattern visitor), ce qui est un gros plus au niveau du gameplay je trouve.
De plus, je n'ai jamais entendu parler de spécialisation de template en java, je ne pense pas que cela soit possible afin d'optimiser les opérations arithmétique en java à l'aide de template comme par exemple le calcul d'une factorielle.
-Impossibilité de passer un pointeurs sur un tableau et un offset pour itérer sur une partie du tableau ce qui, accélère bien les choses lors de la mise à jours du rendu d'une scène. (Les langages modernes masquent les pointeurs, il faut donc faire autrement avec des indices (et non des itérateurs) ce qui ralenti.)
-L'argument de la gestion manuelle de la mémoire ne tiens plus grâce aux nouveaux pointeurs intelligeant du c++11 ainsi que la nouvelle sémantique des rvalues et de toute façon il est très simple d'en faire un en c++ et les nouveaux mot clé using pour les template et auto simplifie grandement la syntaxe face aux infâmes typedef.
(Personnellement j'ai trouvé que la sémantique de toutes ces classes n'est pas si compliquée à comprendre en soit, cependant, je me retrouve encore avec des crashs par endroits qui n'ont pas vraiment lieu d'être, bref, j'espère que je vais pouvoir bien évolué mais je reste confiant.)

Bref, un bon paquets d'arguments qui me font resté sur le c++, mais, bon, flemme de me répéter, je m'en tenir à ce post. (Chacun son langage fétiche, il y en a qui préfère avoir de la simplicité (ce qui est la solution à privilégiée lors du développement d'api non gourmande), d'autres qui préfère le c++. (Plus complexe mais plus rapide et plus flexibile)

[Uther]

Lolilolight> Enfin ta comparaison est limitée aux langages avec un vision principalement haut niveau comme Java, Phyton... Il existe pas mal de langages concurrents du C++ (par exemple le D, Ada, Go, Rust, ...) qui n'ont pas la plupart des défauts que tu cites.

[Matthieu Vergne]

-Il faut savoir que pour copier des listes en java ou bien des tableaux d'objets il faut utiliser arrayCopy car le java cache totalement la sémantique des objets.

Code :

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

1
2
3
 
List<Integer> list = ...
List<Integer> copy = new LinkedList(list);

Je me rappelle pas avoir eu besoin de passer par des tableaux pour faire quoi que ce soit en dehors de l'optimisation de perf.

-Même chose pour les types primitifs, il faut savoir qu'il faut utiliser les classes Integer, Double, etc... pour les référencer.

Pas très pertinent comme argument. En plus que l'équivalence soit facile à retenir (tu fais la faute la première fois mais après ça devient naturel, on ne reste pas débutant toute sa vie), il y a tout de même une différence majeure entre int et Integer (idem pour les autres) : un int ne peut pas être null, un Integer oui. Les types primitifs ne peuvent donc pas être utilisés strictement comme des objets mais restent pratique dans les cas où tu ne veux pas qu'un argument puisse être null. Je verrai davantage une critique sur cette différence, mais pas vraiment sur le fait que tu ne puisses pas utiliser <int> au lieu de <Integer>.

-Les langages modernes, n'offrent pas la possibilité de faire des templates variadiques et donc, de la génération automatique de hiérarchie et du multiple dispatch (cf : le pattern visitor), ce qui est un gros plus au niveau du gameplay je trouve.
De plus, je n'ai jamais entendu parler de spécialisation de template en java, je ne pense pas que cela soit possible afin d'optimiser les opérations arithmétique en java à l'aide de template comme par exemple le calcul d'une factorielle.

Pour les generics variadique (on ne parle pas de tempplates en Java), je te suis. J'aimerais bien avoir quelque chose dans le genre. Cela dit ça reste relativement récent (le C++ ne l'a officiellement que depuis 2011), donc ce n'est pas étonnant de ne pas le voir partout où ça pourrait s'appliquer. Surtout que Java on lui a mis la pression pour autre chose ces dernières années.

Par contre, pour la spécialisation...

Code :

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

1
2
3
4
 
public interface RootInterface<A, B, C> {
  ...
}

Code :

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

1
2
3
4
 
public interface SpecializedInterface1<A, B> extends RootInterface<A, B, B> {
  ...
}

Code :

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

1
2
3
4
 
public interface SpecializedInterface2<A> extends RootInterface<A, Integer, List> {
  ...
}

C'est de ça que tu parles ? Tout à fait faisable en Java, je l'utilise d'ailleurs pas mal.

-Impossibilité de passer un pointeurs sur un tableau et un offset pour itérer sur une partie du tableau ce qui, accélère bien les choses lors de la mise à jours du rendu d'une scène. (Les langages modernes masquent les pointeurs, il faut donc faire autrement avec des indices (et non des itérateurs) ce qui ralenti.)

Quid de Collection.iterator() (qui est donc aussi valable pour les List et Set) ? De plus, selon le type d'utilisation, tu as plein d'implémentations pour optimiser ceci ou cela :
- ArrayList pour un accès lecture/écriture O(1),
- LinkedList pour une liste chaînée facile à faire changer de taille et avec un itérateur O(1),
- HashSet pour aucun doublon et un accès O(log n) par table de hachage,
- LinkedHashSet pour y intégrer une liste chaînée qui permet à l'iterateur d'être plus efficace,
- etc.

Oui, utiliser du Java à la C est bien entendu mauvais, mais ça c'est pas la faute du langage. Faut rester honnête.

[Bousk]

Par contre, pour la spécialisation...

Code :

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

1
2
3
4
 
public interface RootInterface<A, B, C> {
  ...
}

Code :

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

1
2
3
4
 
public interface SpecializedInterface1<A, B> extends RootInterface<A, B, B> {
  ...
}

Code :

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

1
2
3
4
 
public interface SpecializedInterface2<A> extends RootInterface<A, Integer, List> {
  ...
}

Ouah, alors pour spécialiser un template il faut hériter de la base, donc une nouvelle class, donc un nouveau nom ?! pfiou !
Et puisqu'il s'agit d'interface, il faut donc aussi réécrire toute l'implémentation de chaque méthode ? Parce que les interfaces JAVA, merci mais non merci. Ca s'appelle du multi-héritage du mytho.
Une vraie spécialisation de class template c'est std::vector<bool> par exemple.

[Luc Hermitte]

Non, pour la spécialisation il parle de l'unification du Prolog, ou encore l'équivalent du XSLT:

Typiquement, une classe générique peut se voir spécialisée pour certains types (i.e. sa définition ne sera plus la même -- bien que l'on fera en sorte d'avoir une interface générique compatible). Un petit exemple vite pondu, un tableau d'entiers ne ferait pas grand chose sur les entiers, un tableau de fichiers fermerait les fichiers lorsqu'il seraient retirés du tableau. Un seul type tableau générique (donc employable dans d'autres algorithmes génériques externes à la classe tableau), mais avec certains comportements spécialisés suivant ce qui est stocké dans le tableau. Et ce sans dérivation depuis une classe tableau parente, on est sur du pur polymorphisme paramétrique (et statique) et non sur du polymorphisme d'inclusion (et dynamique)

[Matthieu Vergne]

J'ai du mal à voir de quoi vous parler. Un petit exemple ?

En reprenant le coup du tableau de fichiers (ou une liste pour rester objet) :

Code :

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

1
2
3
4
5
6
7
8
 
List<Integer> intArray = new ArrayList<Integer>();
List<FileReader> fileArray = new ArrayList<FileReader>() {
  remove(Object o) {
    super.remove(o);
    ((FileReader) o).close();
  }
};

Quelque chose dans le genre ?

[Flob90]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
template<class T>
struct A
{
    T data;
};
 
//Spécialisation pour void :
template<>
struct A<void>
{ };

(C'est assez inutile comme exemple mais bon)

Un exemple plus utile :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
template<class>
struct return_type;
 
//Spécialisation partielle pour extraire le type de retour d'une signature :
template<class R, class... Arg>
struct return_type<R(Arg...)>
{
    using type =R;
};