Discussion :

[moldavi]

Bonjour.

-plus de pointeur sauf à définir des portions "unsafe" dans le code

En C++ il y a new/delete. En C# il y a new et parfois dispose... Même pas besoin de parler de ces "Pin" pointeurs et autres unsafe design.

En gros si tu oublies de disposer un objet, le programme va fuité. Par contre va chercher la fuite. Je ne parle pas des delagate avec les +=, malheur à toi si tu oublies le -= équivalent. En somme, l'équivalent d'un delete en C++. Bref, garbage collector : loose.

Le garbage collector ne gère rien du tout, sauf si tu fais un simple "Hello world". Ils ont inventé "using" d'ailleurs. Cela veut dire que tu dois quand même gérer le "delete" et savoir ce que tu fais. Donc le garbage collector, c'est juste du Marketing. L'idée est bonne, la réalité beaucoup moins.

Ce qui me fait peur, c'est que le C++ se dirige vers ce type de langage. Et pour lancer un troll, le mot clé "auto" du C++ ne devrait pas exister... (sauf dans une boucle, à la rigueur, à cause des stl type). Le mot clé auto, l'équivalent de var en C#, juste une purge pour la maintenance de code...

[koala01]

Bonjour.

Ce qui me fait peur, c'est que le C++ se dirige vers ce type de langage.

Sauf erreur, il n'est absolument pas question de placer un garbage collector systématique en C++... Au pire, il est peut être éventuellement question de proposer un GC que l'on peut décider d'activer (mais qui serait désactivé par défaut)...
Et encore, il me semble que ce n'était qu'une proposition, je ne sais meme pas si elle a été retenue au final

Les pointeurs intelligents n'ont absolument rien à voir avec un tel mécanisme (bon, allez, les unique_ptr du moins, car on peut éventuellement discuter pour savoir si le fonctionnement de shared_ptr ne calque pas d'une certaine manière le fonctionnement du GC :-S)

Et pour lancer un troll, le mot clé "auto" du C++ ne devrait pas exister... (sauf dans une boucle, à la rigueur, à cause des stl type). Le mot clé auto, l'équivalent de var en C#<snip>

Il n'y a aucun point commun entre le mot clé auto en C++ et va en C# (à moins que je ne me trompe rudement sur ce dernier)!
Le mot clé auto a juste pour objectif de dire au compilateur "je connais le type d'une donnée, mais je suis trop fade pour l'écrire, et tu est parfaitement en mesure de déterminer ce type par toi même". Il permet l'inférence de type, il facilite l'écriture et la lecture du code, mais il n'allège absolument pas la rigueur avec laquelle le type d'une donnée sera traité : si tu définis avec le mot clé auto une variable comme étant une valeur correspondant au retour d'une fonction qui renvoie un int, tu pourras danser sur la tete, tu ne pourras pas utiliser cette variable pour représenter autre chose qu'un int (ou un type équivalent, implicitement convertible en int).

Bien sur, le premier cas auquel on pense avec le mot clé auto est bien sur celui des boucles (range based de préférence), mais, lorsque tu envisages ton développement sous l'angle du paradigme générique, le mot clé auto facilite énormément l'écriture (et la compréhension) du code, sans pour autant te dispenser de connaitre le type exact qui sera utilisé

[moldavi]

Bonjour koala01.

Il n'y a aucun point commun entre le mot clé auto en C++ et va en C# (à moins que je ne me trompe rudement sur ce dernier)!
Le mot clé auto a juste pour objectif de dire au compilateur "je connais le type d'une donnée, mais je suis trop fade pour l'écrire, et tu est parfaitement en mesure de déterminer ce type par toi même". Il permet l'inférence de type, il facilite l'écriture et la lecture du code, mais il n'allège absolument pas la rigueur avec laquelle le type d'une donnée sera traité : si tu définis avec le mot clé auto une variable comme étant une valeur correspondant au retour d'une fonction qui renvoie un int, tu pourras danser sur la tete, tu ne pourras pas utiliser cette variable pour représenter autre chose qu'un int (ou un type équivalent, implicitement convertible en int).

Le mot clé var du C# fait exactement la même chose...

Je dis juste qu'un programme avec des "var"/"auto" de partout sera une purge à maintenir.

Par contre pour celui qui écrit le code, ce sera plus facile. Le C# bat le C++, 3 lettres au lieu de 4....

[bacelar]

maldavi, t'as besoin de vacances.

Je confirme que l'auto C++ et C# sont les mêmes. A ne pas confondre avec le mot-clé "dynamic".

Et putain que c'est cool.

Avec using, c'est exactement comme un capsule RAII, la méthode Dispose servant de destructeur et GC.SuppressFinalize dedans permet d'éviter une balade dans le GC.
http://msdn.microsoft.com/fr-fr/libr...v=vs.110).aspx

maldavi, tu commences à sentir le dinosaures sous naphtaline.
Comme d'hab, il faut savoir s'en servir et pas en abuser. Exactement comme les lambda en C++ ou les async/await .NET.

[koala01]

Bonjour koala01.

Le mot clé var du C# fait exactement la même chose...

Au temps pour moi

Je dis juste qu'un programme avec des "var"/"auto" de partout sera une purge à maintenir.

Personnellement, je ne crois pas...

Je ne parle pas de C# ici, car, sauf erreur (encore une fois), il n'y a pas de séparation entre la déclaration des fonctions et leur implémentation. Mais, en C++, l'idée de base n'est quand même que permettre de n'avoir pas à écrire un nom pleinement qualifié totalement incompréhensible pour récupérer une valeur renvoyée par une fonction!! Et, comme je l'ai déjà dit, cela ne te dispense pas de savoir quel est le type exacte de cette valeur

Si tu as un doute, les fichiers d'en-tête sont toujours là pour te permettre de retrouver ce type et, avec un peu de chance, l'intellisense de ton EDI est peut être meme en mesure de te l'indiquer

L'idée est donc vraiment de permettre au compilateur de ne pas être "plus idiot que l'intellisense" . Personnellement, je pense que, si on fait un minimum attention au nom des services rendus par les différentes classes de nos projets, le lecteur d'un code n'a pas forcément besoin de savoir exactement de quel type est une donnée particulière, pour arriver à le comprendre : la logique d'appel des différentes fonctions doit suffire pour déterminer si la logique est correcte ou non (ou peu s'en faut). Et comme le compilateur est là pour s'assurer que le type de la donnée correspond bien à l'usage que l'on en fait (ou, si tu préfères, qu'on appelle bien des fonctions membres existantes ), tout est pour le mieux dans le meilleur des mondes

D'une certaine manière, ce mot clé nous manquait peut être dans le fait d'inciter les gens à penser en termes de services rendus au lieu de penser en termes de données... Ou, du moins, il nous donne peut être une base sur laquelle baser la justification de ce fait

[DonQuiche]

Je dis juste qu'un programme avec des "var"/"auto" de partout sera une purge à maintenir.

D'après mon expérience en C# à systématiquement utiliser "var" depuis plusieurs années, il accroît au contraire la lisibilité du code et sa maintenabilité. A condition bien sûr d'avoir un IDE qui t'affiche le type dans une tooltip au survol de "var" ou de la variable pour les rares cas où tu as besoin de cette info.

Les causes sont simples :
* Le type est évident 95% du temps et dans la moitié des cas restants on s'en fiche (ça ne gêne pas la compréhension de la méthode et on est concentré sur autre chose).

* Ça réduit la longueur du code, vire la pollution introduite par le typage, favorise l'alignement spatial et réduit le côté patchwork de la coloration syntaxique.

* Dans le cas où tu dois manuellement renommer un type ou changer le type de retour d'une fonction, cela fait deux fois moins d'erreurs à corriger sans pour autant retirer d'erreurs utilis (ou très rarement) : en effet normalement chaque point à corriger requiert de changer le type de la variable puis son utilisation, ici tu n'auras que l'erreur associée à l'utilisation ("pas de méthode MonType.MaMéthode").

[pixelou]

Je ne programme en c++ que sur des projets personnels et de manière générale, je trouve que le langage facilite plus le travaille du développeur que de l'architecte logiciel:
- Il n'y a pas d'interfaces à proprement parler (il faut soit utiliser les méthodes virtuelles qui ont un petit surcoût à l'éxecution, soit le CRTP qui n'est pas très propre).
- pas d'introspection pour vérifier qu'une méthode ou un type est implémenté, même pour du test statique fait par le compilateur (ou alors des techniques très tordues à base de template et de types bizarres).

Niveau syntaxe et organisation du code:
- les macros sont trop limitées, même si constexpr ajoute quelqeus possibilités
- La syntaxe n'est pas très intuitive, même sur les nouveauté introduites par le c++11, pourtant ils n'avaient pas de contraintes à ce moment là.
- les headers ne sont pas utiles pour isoler la partie 'publique', et de toute façon la syntaxe n'est pas assez jolie pour donner envie de les lire. Il y a la documentation ou d'autres outils pour savoir comment sont conçues les classes. En plus avec les templates, le code est étalé dans pleins d'endroits. Je préfèrerais réunir le code dans un fichier avec une gestion manuelle de ce qui est public ou non (un peu comme en java).

Sinon au niveau binaire:
- pas de sérialization. Je n'en ai jamais eu besoin, mais je pense que ça pourrait servir. Par exemple pour envoyer une structure à la carte graphique sour OpenCL, il n'y a pas moyen de savoir si le compilo a réorganisé les membres. Il y a moyen que les fonctions de réseau du C++14 changent ça?
- d'après ce que j'ai vu, l'ABI n'est pas très claire contrairement au C, donc pas une question d'héritage du C sur ce point.

Le débat entre le rapprochement de la syntaxe c++ et java ou autre ne me semble vraiment pertinent. Le C++ propose un maximum de possibilités et pourquoi pas celles introduites dans d'autres langage? La question à se poser serait plus: à partir de quand l'ajout de fonctionnalité nuit au codage (ex: syntaxe trop lourde ou langage trop difficile à appréhender)?
Au final, je ne vois pas beaucoup de défauts relatifs à l'historique du c++.

[jblecanard]

Merci JolyLoic pour ces liens, j'étais passé à côté de ces derniers travaux ! On se sent un peu en retard en C++ sur ces techniques par rapport à des langages dynamiques, mais ce n'est pas étonnant vu la nature non dynamique du langage. Hâte de voir une implémentation dans GCC et Clang !

- pas de sérialization. Je n'en ai jamais eu besoin, mais je pense que ça pourrait servir. Par exemple pour envoyer une structure à la carte graphique sour OpenCL, il n'y a pas moyen de savoir si le compilo a réorganisé les membres. Il y a moyen que les fonctions de réseau du C++14 changent ça?

Et ce mot clé à quoi sert-il ? Il ne faut pas confondre sérialisation et alignement qui sont souvent liés mais restent des sujets séparés. La sérialisation c'est application dépendant, il y a plein de techniques pour le faire. Il y a protobuf et thrift, et maintenant on sait aussi faire un peu d'introspection statique (voir ce projet ou celui-là).

[ternel]

Et aussi delete[] et les smart array pointers