Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

C++ serait-il vraiment victime de son passé ? Pour CoderGears Team
« le plus grand problème du C++ c'est son passé »

Le , par Amine Horseman

72PARTAGES

3  5 
CoderGears Team revient avec une nouvelle analyse concernant le langage de programmation C++. Après avoir affirmé que C++ devra d’abord revoir son mécanisme d’inclusion pour devenir « vraiment un langage moderne », CoderGears Team estime aujourd’hui que « le plus grand problème du C++ c’est son passé »

Rappelons d’abord que la nouvelle norme du langage, sortie en 2011, avait reçu un accueil chaleureux de la part de la communauté C++. « Cependant, à cette année, ce langage avait un passé de plus de 30 ans. Et ce n’est pas facile de convaincre les développeurs que le nouveau C ++ simplifiera les nombreuses facettes frustrantes du langage », proclame l’équipe de CoderGears.

L’exemple donné est la gestion de la mémoire. Pendant de nombreuses années, on utilisait les deux mots clés: "new" pour allouer de l’espace mémoire et "delete" pour libérer l’espace alloué. Ce qui était contraignant surtout c’était qu’il ne fallait pas oublier de libérer la mémoire allouée manuellement. Chose dont les développeurs n’ont plus besoin d’y penser maintenant, puisque le Modern C++ encourage l’utilisation des pointeurs intelligents. Ce serait donc une bonne nouvelle, mais quel est le problème ? Selon CoderGears, le gêne est que « nous avons encore la possibilité d'utiliser new et delete, et bien sûr nous ne pouvons pas éliminer cette possibilité pour de nombreuses raisons » et ils expliquent que tous les efforts de la communauté C++ et les experts du domaine n’étaient pas suffisants pour changer les anciennes habitudes et que « si vous donnez à quelqu'un la possibilité de faire quelque chose avec un langage ou un outil, ne soyez pas surpris s'il le fait ».

Ils donnent aussi quelques exemples pour appuyer leur argument : « il suffit de chercher sur le Web "C++ object allocation" et regardez si le premier lien parle de pointeurs intelligents ». Sinon, « allez dans n'importe quelle bibliothèque universitaire, et demandez un livre C++, et vous trouverez que le chapitre sur l'allocation mémoire et la création des objets parle surtout des mots clés new et delete ».

En résumé : si un nouveau développeur veut apprendre le C++, il va trouver plus de ressources sur le "C avec des classes" que le "C ++ moderne".

Quant aux solutions, l'équipe de CoderGears est d'accord sur le fait qu'il n'y a pas de solution magique. Selon eux, nous pourrons faire en sorte que les compilateurs affichent des avertissements lors de l'utilisation de mots clés et fonctions obsolètes, « mais cette solution n'aura pas un grand impact », et elle conseille aux nouveaux développeurs qui veulent apprendre le C++ de considérer que le langage a changé son nom et s'appelle maintenant "Modern C++". En effet, cela donne un résultat nettement différent dans les recherches sur le web.

Source : CoderGears Blog

Et vous ?

Êtes-vous d’accord avec CoderGears ? Pourquoi ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 03/12/2014 à 9:18
Citation Envoyé par Astraya Voir le message
Je pense que supprimer new et delete est une connerie monumentale qui ne devrait pas avoir débat.
C'est justement la possibilité de pouvoir géré la mémoire de façon custom qui fait la force du C++. Le C++ Modern ne doit pas remplacer les aspects existants, il doit les améliorer/compléter, ce n'est pas la même chose.
Attention, je pense qu'il y a confusion sur le sens de "supprimer". Il n'y a jamais eu la moindre volonté de les supprimer du langage. Quand on parle de supprimer new et delete, il faut comprendre les supprimer de son code. Car 99% du code peut s'écrire sans new et delete, et gagnera énormément à être écrit ainsi.

Citation Envoyé par Astraya Voir le message
Certains métiers n'utilisent pas la STL mais le C++ pure pour plusieurs raisons, notamment que la STL ne répond pas à un besoin spécifique mais à tout les besoins imaginables, ce qui provoque toujours un overhead qui n'est peut être pas acceptable pour certains métier de la programmation.
Mais aussi, hélas, aussi pour de mauvaises raisons... Je ne nie pas que la STL n'est pas adaptée à tous les besoins (même si des alternatives existent généralement, plutôt que tout refaire soi-même), mais j'ai rencontré tant de gens qui croyaient être dans un cas spécial qui méritait de tout refaire (souvent en moins bien au final), que je me méfie désormais quand j'entends ce discours.
7  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 10/12/2014 à 2:19
Citation Envoyé par moldavi Voir le message

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
Citation Envoyé par moldavi Voir le message


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.
Citation Envoyé par moldavi Voir le message


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

Code : Sélectionner tout
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.
7  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 11/12/2014 à 23:03
Citation Envoyé par moldavi Voir le message
C'est marrant parce que "foreach", "in", cela va casser de nombreux code, mais "auto", non... Je ne suis malheureusement pas convaincu par l'argument.
auto était déjà un mot clé du langage, donc non utilisé pour nommé une variable, un fonction ou autre. Et n'était quasiment pas utilisé en pratique (car inutile). Il est possible que du code ait été cassé mais de manière marginale, et en tout cas moins que si on avait utilisé un autre mot clé. Et probablement moins que ce qu'aurait cassé l'usage de foreach ou de in.

Citation Envoyé par moldavi Voir le message
J'ai parlé de génie pour les personnes qui n'ont pas besoin de mettre la souris sur une variable auto pour connaître le type exact.
Je suis ravi d'apprendre que je suis un génie . Plus sérieusement, oui il m'arrive lors de l'usage d'une variable "auto" de mettre la souris pour connaitre son type, mais c'est aussi vrai pour les autres.

D'une part, et c'est la remarque de Loïc, je n'ai bien souvent pas besoin de connaitre le type précis d'une variable, seulement les services qu'elle rends.
D'autre part, pour les variables auto, le type n'est certes pas déclaré mais apparait lors de sa déclaration au travers de la valeur d'initialisation.

Citation Envoyé par moldavi Voir le message
C'est vrai qu'au bout de plusieurs utilisations, un for(A : B) deviendra naturel. Mais un foreach(A in B) l'est cent fois plus. Si des choses du langage permettent de coller au mental de l'homme, pourquoi ne pas le faire. Les débutants se sentiront plus à l'aise.
Au bout de plusieurs utilisation ! Tu plaisantes, une devrait suffire à quelqu'un de raisonnablement intelligent et disposant d'un minimum de vernis C++. Après tout for est déjà ce qui permet d'itérer sur un ensemble de valeur.
foreach(A in B) l'est certes un peu plus, mais la différence est minime. Et ce n'est certainement pas ce qui rends le langage difficile d'accès.
6  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 13/12/2014 à 15:34
Un exemple où un auto entier m'a aidé ? Passage en 64 bits d'un code contenant à la fois des collections STL et des collections maisons que l'on vire peu à peu où les indices et tailles étaient gérées en signed int. Donc en gros plein de confusions et de casts entre int, size_t, unsigned_int, long, unsigned long....
Quand je vois :
Code : Sélectionner tout
int elementCount = maCollection.size();
Je n'ai aucune idée si le code en question est correct ou pas, et s'il va le rester.
Si à la place j'ai
Code : Sélectionner tout
auto elementCount = maCollection.size();
Je sais que mon code est forcément correct. L'équivalent
Code : Sélectionner tout
TypeDeMaCollection::size_type  elementCount = maCollection.size();
Me semble moins intéressant, car il m'impose de connaitre le type exact de ma collection, alors que celui-ci peut varier au cours des refactorings.
6  0 
Avatar de Epok__
Nouveau membre du Club https://www.developpez.com
Le 28/11/2014 à 22:38
Citation Envoyé par sizvix Voir le message
c'est, je trouve, une contrainte plutôt positive de faire un plan et de le suivre, et ça permet d'avoir un résumé clair de la classe, même si les IDE actuels permette d'afficher de tel prototypes facilement avec des classes dans d'autres langages.
Je suis d'accord avec ça, j'aime avoir un plan clair de ma classe. Mais je pense juste que c'est le genre de tâche automatisable très facilement.
C'est une tâche extrêmement automatique, que de faire la liste des fonctions.

En général, j'écris le prototype dans le header, et je génère automatiquement le corps avec l'IDE.

Mais autant quand je développe en C (très bas niveau en général, parfois sans OS) je comprend la nécessité du header : j'en fais parfois plusieurs pour une même librairie, un public et un privé par exemple.
Mais en C++, où la notion de public et privé est explicite, on écrit toujours le header de la même manière, strucutré, etc. D'où, automatisable.

Je pense juste que là dessus, la norme pourrait prévoir un outil pour réaliser cette tâche, tout en laissant la possibilité bien sûr de le faire manuellement.
Par exemple, rechercher dans la liste des fichiers compilés si la classe existe pour en extraire les infos nécessaires si aucun header n'est spécifié pour la classe.
Les meta-infos de type static, private, etc. devraient bien sûr alors être répétées dans le .cpp.
Mais cela pourrait au moins faciliter la tâche pour les classes au sein d'une même librairie.

Je rêve peut-être, mais n'est-ce pas le sujet de l'article ?

Citation Envoyé par Guikingone Voir le message
J'ai toujours considérer le C++ comme une alternative au C, en moins bien cependant, le C reste à mes yeux un modèle, il est touffu, complexe et déroutant mais il forme des dévs de qualité qui savent mettre les mains dans la sauce sans rechigner et qui savent gérer un language strict.

Le C++ n'est pas mauvais en soi, disons qu'il différe du C en une version moins directe et moins "lisible" à mes yeux, mais là encore, chacun y verra midi à sa porte.
J'ai, au début, considéré le C++ comme une extension du C.

Moi qui venait du C, bas niveau, strict, avec une gestion de la mémoire au plus proche, j'ai au début été très dérouté.
Ma première approche du C++ a été d'y voir un artifice d'« enrobage » du C dans une couche haut niveau. Du C pour les flemmards, presque ^^.

Mais après un usage un peu plus poussé maintenant, je ne vois en fait aucune similitude entre ces deux langages.
Une même syntaxe, bien sûr. Une compatibilité, effectivement.
Mais un style, une manière de raisonner qui se situaient sur des niveaux tellement différents qu'il est impossible de les comparer.

Pour moi, le C et le C++ sont deux langages totalement différents, et cela s'accentue je trouve avec les dernières révisions du C++, pour le meilleur.

Mais je crois qu'il est possible d'enrichir le C++, par exemple comme expliqué ci-dessus, sans pour autant casser la compatibilité. Et donc contenter à la fois les devs haut niveau comme ceux plus proches du matériel.
5  0 
Avatar de jo_link_noir
Membre expert https://www.developpez.com
Le 11/12/2014 à 1:30
Citation Envoyé par moldavi Voir le message
Pourquoi for(a : b), ce n'est pas foreach(a in b) ??
Par ce qu'introduire un nouveau mot clef est très risqué: problème de compilation. Un code utilisant decltype ou noexcept pour des noms de variables/fonctions, n'est pas compilable en C++11 (pas de problème avec final ou override, leur ajout est sans ambiguïté).
Alors ajouter des mots couramment utilisés comme 'in' ou 'foreach' est impossible sans casser de nombreux codes.

Et non, std::for_each et for(T a:c) ne sont pas pareil. Le premier est une fonction qui prend des itérateurs comme n'importe quel algorithme de la sl. Le second est du sucre syntaxique qui fonctionne sur des containers (plus précisément un type qui supporte std::begin(T&/std::end(T&). Et pas besoin d'être un génie pour comprendre la boucle.

Note que C++ n'est pas le seul à proposer for pour boucler sur une collection: bash, javascript, ruby, etc. Et même si la plupart utilisent en plus 'in', ce n'est pas le cas de tous : D, php, Go, Scala.
(En cherchant pour ruby je suis tombé sur ça: https://en.wikipedia.org/wiki/Foreach_loop, certain n'ont même pas de mot définit pour faire un foreach ).
5  0 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 12/12/2014 à 14:39
Il faut voir "auto" en conjonction avec les templates.

Quand on écrit une fonction template:

Code : Sélectionner tout
1
2
3
4
5
6
template< typename T >
void maFonction( T & maVariable )
{
    maVariable.vasy();
}
Est-ce que quelqu'un est choqué de ne pas connaître le type de maVariable? non. Il faut juste que le type ait une fonction nommé "vasy" et ça compile, c'est tout ce qu'on lui demande.

Donc quand on a l'habitude de ce code là (un des gros intérêt du C++), on comprend tout de suite l'intérêt du "auto", si on a par exemple:

Code : Sélectionner tout
1
2
3
4
5
6
template< typename T >
typename T::type_de_retour maFonction( T & maVariable )
{
    return maVariable.vasy();
}
On peut passer n'importe quel objet à maFunction, il faut qu'il réponde au contrat:
- J'ai une fonction vasy
- J'ai un "type_de_retour"

Toute la librairie C++ est sur ce principe (on est pas obligé de tout comprendre pour l'utiliser). Du coup l'utilisateur peut faire un simple

Code : Sélectionner tout
1
2
auto ret = maFonction( monObjet );
Sans être obligé de voir tous les rouages de la lib en dessous.

Pour le for_each:

Sinon pour le coup du "in", c'est assez simple: si on rajoute un mot clé "in", alors tous les codes qui utilisent "in" comme nom de variable ou nom de fonction vont être cassés. Alors que ":" et "auto" faisaient déjà partis des mots clés interdits.

for_each correspond à la norme d'écriture de la lib C++. Son but principal était d'appeller une fonction ou un functor sur chaque élement d'un container.
5  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 13/12/2014 à 2:29
Citation Envoyé par moldavi Voir le message
Le cassage de code source avec "foreach"/"in", je ne l'avalerai pas sans preuve. J'attends toujours les liens de milliers de code source potentiellement vulnérable à cette update...
Il n'y en a sans doute pas des milliers, mais ils existent (pour foreach au moins, j'en suis sur. Certains aiment bien redévelopper la bibliothèque standard, mais sans utiliser sa politique de nommage).
Et même il n'y en aurait qu'un, c'est toujours un de plus que tu casses en utilisant foreach/in plutôt que for( : )

Citation Envoyé par moldavi Voir le message
Donc lorsque tu vois auto, tu sais déjà les services rendus par auto. Des génies, vous êtes. Quand je vois auto, je ne vois rien, parce que cela ne veut rien dire. Par contre lorsque je vois IMaSuperInterface, là je sais que la variable fait de supers choses...
Les variables ont aussi (et surtout) un nom ! Et lorsque les gens nomment à peu prés correctement les choses, ce nom indique son rôle et donc les services qu'elle rend.
Et étrangement, ce nom m'apprends souvent bien plus de choses que de connaitre le type précis. D'autant que contrairement au type il apparaît aussi lorsque j'utilise ladite variable et pas uniquement lorsque je la déclare.

Et dans les cas où le type est réellement important, ben je le déclare. Mais ça ne m'empêche pas d'utiliser auto le reste du temps ni ne me fais cracher sur celui-ci.

Citation Envoyé par moldavi Voir le message
C'est vrai, c'est le cas "normalement" le plus fréquent.
Si tu utilises auto, tu as forcément une valeur d'initialisation, ce n'est pas juste "normalement le plus fréquent).

Citation Envoyé par moldavi Voir le message
Le cas des "template" (cf post précédent) montre un autre cas
Les règles de déduction de type sont similaire entre template et auto. Mais à part ça je ne vois ce que viennent faire les templates par rapport à la phrase que tu cites.

Citation Envoyé par moldavi Voir le message
et le "auto i" en place de" int i" un autre.
Je ne vois pas de différence fondamentale entre int et un autre type en ce qui concerne l'usage d'auto. Du coup je ne vois pas quel cas particulier tu cherches à mettre en évidence.

Citation Envoyé par moldavi Voir le message
La différence est loin d'être minime. Tout ce qui colle au mental sera compréhensible, sans connaissance experte du langage.
Je pense que là, on a une vrai divergence de point de vue. Je n'estime pas que la connaissance de la syntaxe de base d'un langage est "un connaissance experte du langage". Et la signification de for( : ) est de la syntaxe de base.

Et au passage, foreach/in, au moins dans mon cas, ne "colle pas plus au mental" que for( : ) (j'ai malheureusement tendance à penser et à réfléchir en français).
5  0 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 13/12/2014 à 10:38
et encore, on a pas parlé des lambdas...

mais bon après, on utilise auto si on veut ou pas, on est pas obligé. Je ne vois personnellement pas ce que ça change si on a l'habitude d'utiliser des templates et de pouvoir passer d'un container à un autre sans modification de code.

On parle de auto à la place de int dans un exemple, mais généralement c'est plutôt à la place de std::vector< std::map< std::string, std::vector< std::string > > >::iterator
5  0 
Avatar de gl
Rédacteur https://www.developpez.com
Le 19/12/2014 à 0:17
Citation Envoyé par moldavi Voir le message
Donc pour vous, développez une application "classique" comme je le mentionne, est la même chose que développer une bibliothèque.
C'est surtout que la barrière me semble très artificielle ou tout au moins ne correspond pas du tout à mon vécu.

Il y a effectivement une différence dans le livrable, je te l'accorde.
Mais en terme de code, je te suis moins.

Dans tous les projets applicatifs sur lesquels je suis intervenu (de près ou de loin), j'ai toujours eu besoin de développer du code générique, réutilisable, rendant de multiple. bref faisant intervenir ce que tu sembles classé comme du code de bibliothèque (template notamment) que ce soit sur du code utilisé exclusivement dans cette application ou partagé entre plusieurs applications (codes qui sont généralement modularisés sous forme de bibliothèque d'ailleurs).
Et à contrario, sur les projets bibliothèques, il y a d'immenses pans qui n'utilisent pas ces techniques (ne serait-ce que les tests et exemples) et de nombreuses bibliothèques adressent un besoin extrêmement précis et n'ont pas vocation à être généralistes.
Et souvent ce sont les mêmes personnes qui interviennent sur les deux types projets

Il est fort possible que dans ton domaine d'activité la séparation soit franche et la distinction très claire. Mais ce n'est pas généralisable à tous les domaines. Et dans ces domaines, développer une application ou développer une bibliothèque ne sont pas, en terme de développement, fondamentalement différents.
5  0