Discussion :

[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

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

[moldavi]

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

J'aime beaucoup ton humour, et le "maldavi" m'a bien fait rigoler...

Cela me rappelle aussi une personne qui m'a demandé en privé si j'étais Moldave. Je lui expliqué que j'étais un fan des bd de Tintin (les connaisseurs et les curieux comprendront l'origine de mon pseudo. Il manque un "e" et je ne saurais en expliquer la raison).

Ce n'est pas parce que je critique, que je suis aigri ou un dinosaure. Je fais part de mon jugement pour faire réfléchir et faire avancer le débat.
Bien sûr, ce faisant, j'avance quelque sorte de véracité que je peux remettre en cause le lendemain. Mais il me faut quand même des arguments valides.

Ce que je dis avec using et dispose, c'est que le développeur doit savoir quand les utiliser. Donc quelle est la différence avec new/delete du C++ ? (allez, répondez à cette phrase avec citation... pas celles qui vous arrange)

Oui il faut savoir s'en servir comme tu le dis. Par contre je ne comprends pas :

Comme d'hab, il faut savoir s'en servir et pas en abuser.

Il n'est pas question d'en abuser ou pas. Il faut disposer ou pas. Il faut donc comme en C++, faire un delete quand c'est nécessaire. Donc le garbage collector ne gère pas du tout les ressources à ta place, et de toute façon il ne peut pas. Le développeur est responsable de la gestion de ses ressources.
Oui le GC en gère une grosse partie, mais pas toute.

J'explique surtout que les GC, c'est une bonne idée pour faciliter le travail des développeurs, mais que c'est loin d'être le Saint-Graal. Si cela peut aider des développeurs dans leur choix, je ne regrette rien.

[bacelar]

Salut Moldavi,

Désolé pour la typo.

différence avec new/delete du C++ ?

Bin, y a un new mais pas de delete.
C'est using qui se démerde, exactement comme le RIIA en C++.

Il n'est pas question d'en abuser ou pas. Il faut disposer ou pas.

Ca dépend du type d'objet.
Une transaction de base de données, c'est pas la même chose que le résultat d'un calcul intermédiaire pour un cache.

Il faut donc comme en C++, faire un delete quand c'est nécessaire

Non, pas de delete, mais des using. En C++ Modern on ne fait plus qu'exceptionnellement des delete.

Le développeur est responsable de la gestion de ses ressources.

Oui, le GC, c'est comme une clé à molette, c'est un outil et la qualité du travail correspond à la maitrise de l'outil par l'ouvrier.

mais que c'est[GC] loin d'être le Saint-Graal

+1

On est donc d'accord.
C'est juste que moi, j'aimerais bien avoir un ceinturon avec tout plein d'outils argentés pour butter les méchants bugs, tel un Van Helsing digital.

H.S.: je regarde en ce moment le support de l'asynchronisme dans .NET5, il y a un truc équivalent en C++ dans les tuyaux ?

[Neckara]

Bonjour,

H.S.: je regarde en ce moment le support de l'asynchronisme dans .NET5, il y a un truc équivalent en C++ dans les tuyaux ?

Tu veux parler de std::future ?

[JolyLoic]

Bin, y a un new mais pas de delete.
C'est using qui se démerde, exactement comme le RIIA en C++.

C'est proche, mais pas identique. En particulier, l'utilisateur n'est pas obligé d'utiliser using, alors qu'en C++ on peut faire que l'interface ne retourne que un wrapper RAII.

H.S.: je regarde en ce moment le support de l'asynchronisme dans .NET5, il y a un truc équivalent en C++ dans les tuyaux ?

Tu parles de async/await ? Oui. Mais ce n'est pas encore finalisé. En particulier, c'est beaucoup plus difficile à faire en C++ à cause des destructeurs. Et les gens se dirigent vers une implémentation totalement différente (aux dernières nouvelles, plusieurs piles, on bascule de l'une à l'autre, et non pas une réécriture de la fonction sous forme d'automate à état). Un des derniers papiers sur le sujet est http://www.open-std.org/jtc1/sc22/wg...2014/n4286.pdf. Et la version beta de visual studio 2015 en implémente une version, basée sur http://isocpp.org/files/papers/N3858.pdf.

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

[moldavi]

Bonjour.

Salut Moldavi,
Désolé pour la typo.

Dommage, j'avais vu un trait d'humour : maldavi = mal d'avis (en gros, mon avis est mauvais...).

Le C++ doit évoluer, pas de problème. J'attendais le for_each depuis longtemps. Mais ce n'est pas un mot clé. Je me demande aussi l'intérêt de l'underscore dans for_each... Peut-être que foreach est breveté.

Quitte à aller au bout des choses, je vois deux choses pour var et auto :

- Pourquoi pas v pour var et a pour auto. Si cela doit être simple, autant n'avoir qu'une lettre à taper dans l'éditeur. C'est quand même plus simple que var (3 lettres) et auto (4 lettres). Il faut aller au bout du raisonnement.

- Et puis si intellisense peut résoudre le type de la variable, alors pourquoi écrire var/auto. Encore plus simple :

Code :

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

1
2
 
Toto = CreateVariableThatYouHaveToSetMouseOnTotoToKnowWhoIsIt();

Trop cool, même pas besoin d'écrire var/auto...

Il ne manque que le $, et le tour est joué.

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

[moldavi]

Bonjour DonQuiche.

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.

C'est là où nous ne serons jamais d'accord. Je n'ai pas envie de survoler var/auto avec ma souris pour savoir quelle est le type de la variable. Une perte de temps. Mes yeux me suffisent et j'aime bien avoir le moins de mouvements de souris à effectuer... Surtout après 7 heures de développement dans la journée.

Si je ne me trompe pas, tu avoues implicitement que sans intellisense, la lisibilité et la maintenance sont ralenties. Faire un mouvement de souris superflu ralenti aussi la chose. Si le nom de la variable est explicite (pas de var/auto), pas de mouvement de souris, donc gain de temps.

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

C'est vrai que c'est souvent évident (pour les 95%, j'attends l'étude), mais cela demande à ton cerveau de faire la déduction. Si je peux faire l'économie de deux/trois neurones, alors je milite.

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

Cela réduit la longueur de code, mais cela n'est pas cohérent. Pourquoi pas v ou a alors. Et pourquoi pas rien, comme en php (sauf le $) ? Allez jusqu'au bout du raisonnement.

Pour le reste, et surtout l'histoire de la pollution, je ne comprends pas. Autant faire du Brainfuck, si vous pensez minimaliste. La simplification a ses limites...

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

Que tu changes le nom de la variable ou les méthodes de la variable, le gain n'est pas mesurable. Il sera fluctuant selon les changements.

Et si tu ne changes que le nom de la variable, il paraît que les IDE peuvent refactoriser le tout en trois clics...

[JolyLoic]

Le C++ doit évoluer, pas de problème. J'attendais le for_each depuis longtemps. Mais ce n'est pas un mot clé. Je me demande aussi l'intérêt de l'underscore dans for_each... Peut-être que foreach est breveté.

Le for-each en C++ s'écrit for(a : b), std::for_each est un algorithme dont l'intérêt est limité par rapport au vrai for-each

Quitte à aller au bout des choses, je vois deux choses pour var et auto :

- Pourquoi pas v pour var et a pour auto. Si cela doit être simple, autant n'avoir qu'une lettre à taper dans l'éditeur. C'est quand même plus simple que var (3 lettres) et auto (4 lettres). Il faut aller au bout du raisonnement.

Parce que la réduction du nombre de lettres n'est pas le seul avantage de auto (loin de là... J'utilise même auto pour des int, alors qu'il y a plus de lettres).
Sinon le nombre de lettre est effectivement un argument pertinent pour sélectionner un mot clef du langage, mais à équilibrer avec la lisibilité. if (a == b) me semble par exemple un meilleur choix que if(a.equals(b)) ou que if_the_next_condition_is_true(a==b). Mais on a quand même choisi if et non pas i.

- Et puis si intellisense peut résoudre le type de la variable, alors pourquoi écrire var/auto. Encore plus simple :

Code :

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

1
2
 
Toto = CreateVariableThatYouHaveToSetMouseOnTotoToKnowWhoIsIt();

Trop cool, même pas besoin d'écrire var/auto...

Il ne manque que le $, et le tour est joué.

Parce que là, on ne peut plus différentier création d'une nouvelle variable et tentative de réutilisation d'une variable existante mais qui a échouée suite à une faute de frappe.



Sinon, je pense que si tu es gêné par le fait qu'auto te rende moins visible le type exact de ta variable, je pense que tu es passé à côté de la principale fonctionnalité d'auto, qui est justement... de rendre moins visible le type exact de ta variable Et je parle bien de fonctionnalité, et non d'effet secondaire !

Ce qui est important dans le code, ce n'est pas le type d'une variable, c'est avant tout son rôle. Le type est un détail d'implémentation, qui permet juste de définir formellement les opérations réalisables sur une variable, et qui peut varier au fil des évolutions du code, là où le rôle est plus stable. Quand je récupère une position dans une collection, je me contrefous de savoir si c'est un std::vector<int>::iterator, un std::list<float>::const_iterator, ou un Element*.

Tout ce qui compte, c'est de savoir que c'est une position dans un conteneur. Et que je peux lui appliquer les opérations que l'on peut appliquer à toutes les positions dans ce type de conteneur. Et ça, je le sais en regardant comment la variable est initialisée. auto i = maListe.begin(); me semble bien plus claire que si on devait préciser le type. D'ailleurs, je suis certain que tu as compris de quoi je parlais, alors même que tu ne sais pas quel est le type de maListe.

Auto est un mécanisme d'abstraction. Finalement, dire "utilisez auto" en C++ est très proche de dire "écrivez votre code en fonction des interfaces, pas des types concrets" en Java/C#. Certain veulent rendre la situation encore plus similaire, en introduisant un intermédiaire entre type exact et type non spécifié, qui consisterait à écrire, dans l'exemple précédent : Iterator<int> i = maListe.begin(); (Iterator étant un concept). Certains veulent une alternative juste un peut moins précise : Iterator<auto> i = maListe.begin();. Je ne me suis pas encore forgé une opinion sur ces alternatives, mais que sais qu'entre auto et le type exact, auto me permet d'écrire du code plus lisible et plus maintenable.

[bacelar]

Brainfuck a été optimisé pour rendre simple son interpréteur.
Nous, on cherche à optimiser notre lecture et compréhension du code.
La programmation générique et la méta-programmation montrent que le type d'une variable, c'est très rarement une chose importante et pouvoir en changer facilement, c'est un très gros plus.
Avant les templates, on utilisait les defines pour pouvoir avoir les neurones libres de tout ce fatras.

var à la place de variable ou de v, c'est pour moi un très bon compromis pour ma compréhension. Et je pense pour une très grande majorité des développeurs.
Je laisse aux spécialistes des neurosciences le pourquoi de cette chose aussi naturelle répandu que cette constatation.

Nous ne sommes pas des compilateurs, il faut que le langage soit adapter la psychologie humaine.

[mintho carmo]

std::for_each est un algorithme dont l'intérêt est limité par rapport au vrai for-each

(HS : avec les travaux du SG parallel, l'utilisation de for_each peut être intéressant vs range-based for, puisque cela faciliterait le passage à une version parallèle de cet algo, en conservant la syntaxe)

[Jean-Marc.Bourguet]

J'attendais le for_each depuis longtemps. Mais ce n'est pas un mot clé. Je me demande aussi l'intérêt de l'underscore dans for_each...

Il est normalisé que depuis 1998. L'underscore est cohérent avec le nommage de cette partie de la bibliothèque (find_if, copy_backward, etc)

[mintho carmo]

(il confondait range-based for et std::for_each... enfin, je crois j'espère)

[moldavi]

Bonjour.

Il est normalisé que depuis 1998. L'underscore est cohérent avec le nommage de cette partie de la bibliothèque (find_if, copy_backward, etc)

Merci pour cette information. C'est très cohérent en effet.

[moldavi]

Bonjour JolyLoic.

Le for-each en C++ s'écrit for(a : b), std::for_each est un algorithme dont l'intérêt est limité par rapport au vrai for-each

D'accord, plusieurs façons de faire, un peu le bordel quoi... Je l'avais oublier le for(a : b) : si c'est un foreach, alors je ne comprends pas la subtilité. Ce que je vois, c'est qu'on veut faire "style" plus fort que les autres. "for" au lieu de "foreach" (on gagne 4 lettres). ":" au lieu de "in", on gagne une lettre. for(a : b) ne ressemble en rien à un foreach. A vouloir Brainfuckiser à outrance, cela n'a plus de sens.

Pourquoi for(a : b), ce n'est pas foreach(a in b) ?? Mentalement, même un non informaticien comprendra la deuxième version...