Journal C++Now 2014

Posté par rewind (Mastodon) le 25 mai 2014 à 16:02. Licence CC By‑SA.

Étiquettes :

mai

2014

Entre le 12 et le 17 mai dernier a eu lieu C++Now qui se définit comme un rassemblement d'experts et de passionnés de C++ venant de partout dans le monde. Et on peut dire que le programme était alléchant. Au menu, tout un tas de présentation sur C++, en particulier ses versions 11 (déjà sortie) et 14 (la prochaine) voire 17 (la suivante).

Il faut dire que C++11 a apporté plein de nouvelles fonctionnalités qui ont révolutionné la manière de penser et de concevoir en C++. Le «move semantics» en particulier a ouvert des opportunités jusqu'à présent impensables mais amène également tout un tas de difficultés qu'il faut résoudre. La notion de valeur a pris une tout autre tournure depuis C++11. Les premières briques de programmation parallèles doivent être complétées. Bref, C++ a une nouvelle jeunesse.

Les présentations sont quasiment toutes en ligne. Parmi mes préférées :

Removing undefined behavior from integer operations: the bounded::integer library : des ensemble d'entiers comme dans Ada avec vérification à la compilation ou à l'exécution, au choix.
C++11 Library Design : l'art et la manière de faire une bonne bibliothèque en C++11 (j'aime beaucoup la liste des briques qui manquent cruellement dans la bibliothèque standard à la fin, où on voit aussi que ça risque de s'améliorer bientôt quand même)
Multiplatform C++ : toute la difficulté de faire du multi-plateforme…
Unicode in C++ : un petit rappel de ce qu'est Unicode et de son statut dans C++ (j'ai beaucoup rigolé sur les slides qui présentent la liste des fonctionnalités dans C++)
Designing XML API for Modern C++ : une API XML moderne et sympa, à la limite entre DOM et SAX
Understanding && : vous n'avez toujours pas compris ce que && signifie ? pas sûr qu'avec cette présentation vous soyez mieux éclairé
Value Semantics: It ain't about the syntax! : une très longue réflexion (584 slides !) sur la notion de valeur en C++

Prochaine étape pour tous ces gens là (oui, c'est toujours un peu les mêmes qu'on retrouve dans ce genre de manifestation) : CppCon début septembre. Il n'y a pas encore le programme mais ça risque d'être d'aussi bonne qualité. Herb Sutter, qui est en charge du comité de normalisation, a évoqué les propositions de présentations qu'il a envoyées et qui sont des sujets récurrents (limite des trolls) : la définition d'une ABI pour C++ et C++ et les garbage collector.

# Syntaxe étonnante

Posté par Julien Jorge (site web personnel) le 25 mai 2014 à 20:08. Évalué à 4.
Dans la présentation sur bounded::integer, il y a une classe dont la syntaxe des fonctions m'étonne (classe Goblin, slide 25). Ça ressemble à cela :
```
class G {
public:
  auto f() -> void {
    ++m_h;
  }

private:
  int m_h;
};
```
Quelqu'un peut-il m'expliquer la déclaration de G::f ? Ça ressemble à la syntaxe des lambda avec une déduction automatique du type de f. Je pensais que ça serait une variable de type fonction nommée f mais GCC n'est pas d'accord.
- [^] # Re: Syntaxe étonnante
  
  Posté par Julien Jorge (site web personnel) le 25 mai 2014 à 20:38. Évalué à 10.
  Bon finalement j'ai trouvé. Pour ceux qui se posent aussi la question, il s'agit de la nouvelle syntaxe C++11 de déclaration de fonctions, où le type de retour est indiqué après la flèche et le nom est précédé du mot clé auto.
  
  Ici la déclaration de G::f est équivalente à
```
class G {
public:
  void f() {
    // …
  }
};
```
  Comme le type de retour (nommé trailing return type) est indiqué après la fonction, il est interprété dans le contexte de la fonction. Par exemple (inspiré de cette source), si j'écris
```
class C {
public:
  enum E { a, b, c };

  E f();
  auto g() -> E;
};
```
  Je dois implémenter C::f en préfixant le type de retour avec le nom de la classe :
```
C::E C::f() {
  // …
}
```
  Tandis que la nouvelle syntaxe m'épargne ce préfixe pour C::g :
```
auto C::g() -> E {
  // …
}
```
  Ici le type de retour est bien C::E, c'est à dire E interprété dans le contexte de C.
  
  C'est super car j'ai économisé l'écriture de C:: au prix de l'écriture de auto -> ! Je ne me suis pas fait avoir…
  
  En fait l'intérêt est surtout lié à l'arrivée de decltype. On peut ainsi déclarer le type de retour en fonction des entités apparaissant dans la signature de la fonction, comme dans l'exemple suivant :
```
template<class T, class U>
auto add(T t, U u) -> decltype(t + u);
```
  Ici la fonction add retourne une valeur du même type que le résultat de operator+ sur les paramètres. Si T et U sont int, alors le type de retour est int ; si T est int et U est double, le type de retour est double.
  
  Une troisième source sur le sujet.
  - [^] # Re: Syntaxe étonnante
    
    Posté par needs le 26 mai 2014 à 06:41. Évalué à 10.
    
    Ça m'énerve, les nouveautés du C++11 ne font que complexifier le langage plus qu'autre chose. Mais comment voulez vous que des programmeurs apprennent et aient en tête les mille et une fonctionnalités du langage ? Beaucoup de projets font volontairement le choix d'utiliser qu'un sous-ensemble plus ou moins restreint du langage, pour que la barrière d'entré reste relativement basse.
    
    Je souhaite d’ailleurs bien du courage à ceux qui vont implémenter ce genre d’éléments dans le compilateur, parce que dans le genre syntaxe qui pète tout, on est pas mal.
    
    J'ai l'impression qu'ils (les auteurs de la norme C++11) essayent de faire des mécanismes pour obtenir du code ultra-générique mais ne se rendent pas compte que la contre partie est très importante. D'une part, le besoin de faire un code générique ne se rencontre que rarement, et d'autre part, ont perd souvent beaucoup en lisibilité et simplicité. C'est pas comme si c'était déjà difficile d'écrire du code illisible et non maintenable avec ce langage.
    
    Et parfois c'est mieux d'avoir à écrire plus de ligne de code pour éviter d'empiler inutilement les couches. Parce qu’on écrit pas du code pour qu'il soit le plus concis possible, mais le plus simple et compréhensible possible.
    
    Et non, ce n'est pas un troll, le C++ est beaucoup trop gros et sa courbe d'apprentissage ne fait que s'élever de norme en norme.
    - [^] # Re: Syntaxe étonnante
      
      Posté par David Demelier (site web personnel) le 26 mai 2014 à 09:18. Évalué à 3. Dernière modification le 26 mai 2014 à 09:19.
      
      Ça m'énerve, les nouveautés du C++11 ne font que complexifier le langage plus qu'autre chose. Mais comment voulez vous que des programmeurs apprennent et aient en tête les mille et une fonctionnalités du langage ? Beaucoup de projets font volontairement le choix d'utiliser qu'un sous-ensemble plus ou moins restreint du langage, pour que la barrière d'entré reste relativement basse.
      
      Non, ces nouvelles fonctionnalités sont : 1. Optionnelle, 2. Réponde à un besoin précis. Avec la nouvelle syntaxe de retour on est plus obligé de spécifier le paramètre de retour de type template (très utile dans un DP factory) par exemple.
      
      Au lieu de faire :
      
      Window w = build(myfactory, "foo", "bar", "baz");
      
      On peut maintenant faire :
      
      Window w = build(myfactory, "foo", "bar", "baz")
      
      En utilisant notamment auto -> decltype(myfactory.build()) par exemple
      
      J'ai l'impression qu'ils (les auteurs de la norme C++11) essayent de faire des mécanismes pour obtenir du code ultra-générique mais ne se rendent pas compte que la contre partie est très importante. D'une part, le besoin de faire un code générique ne se rencontre que rarement, et d'autre part, ont perd souvent beaucoup en lisibilité et simplicité. C'est pas comme si c'était déjà difficile d'écrire du code illisible et non maintenable avec ce langage.
      
      Tu as raison, vaut mieux faire du code non générique ou alors avec des void *, c'est génial ça :-). Et puis au passage, écrire des bibliothèque en template ont l'avantage de ne pas surcharger le binaire final si on ne s'en sert pas. "You don't pay for what you don't use"
      
      Et parfois c'est mieux d'avoir à écrire plus de ligne de code pour éviter d'empiler inutilement les couches. Parce qu’on écrit pas du code pour qu'il soit le plus concis possible, mais le plus simple et compréhensible possible.
      
      Je ne vois pas de quelles couches tu parles…
      
      Et non, ce n'est pas un troll, le C++ est beaucoup trop gros et sa courbe d'apprentissage ne fait que s'élever de norme en norme.
      
      Comme je l'ai dit au dessus, tu n'es pas obligé de tout utiliser. On peut très bien développer en C++ sans lambda, sans template et même sans namespaces. Mais lorsqu'on rencontre un problème précis, ça peut être très utile de commencer à apprendre ces fonctionnalités.
      
      git is great because linus did it, mercurial is better because he didn't
      - [^] # Re: Syntaxe étonnante
        
        Posté par claudex le 26 mai 2014 à 09:24. Évalué à 10.
        
        Au lieu de faire :
        Window w = build(myfactory, "foo", "bar", "baz");
        On peut maintenant faire :
        Window w = build(myfactory, "foo", "bar", "baz")
        
        J'ai l'impression de passer à côté de la différence.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Syntaxe étonnante
        
        Posté par rewind (Mastodon) le 26 mai 2014 à 09:27. Évalué à 6.
        
        Je pense qu'il voulait dire :
        
        Window w = build<Window>(myfactory, "foo", "bar", "baz");
        
        vs
        
        Window w = build(myfactory, "foo", "bar", "baz")
        
        [^] # Re: Syntaxe étonnante
        
        Posté par David Demelier (site web personnel) le 26 mai 2014 à 09:57. Évalué à 2.
        
        Oui pardon, j'ai pas réussi à mettre le code en avec les chevrons en bloc. :-(
        
        git is great because linus did it, mercurial is better because he didn't
      - [^] # Re: Syntaxe étonnante
        
        Posté par Troy McClure (site web personnel) le 26 mai 2014 à 13:21. Évalué à 2.
        
        Et puis au passage, écrire des bibliothèque en template ont l'avantage de ne pas surcharger le binaire final si on ne s'en sert pas. "You don't pay for what you don't use"
        
        Si le linker fait bien son boulot d'elimination du code mort dans tous les cas tu ne payes pas pour ce que tu n'utilises pas (on pourrait aussi rajouter qu'avec les templates tu payes déjà le prix fort en temps de compilation)
      - [^] # Re: Syntaxe étonnante
        
        Posté par groumly le 27 mai 2014 à 00:26. Évalué à 4.
        
        Tu as raison, vaut mieux faire du code non générique ou alors avec des void *, c'est génial ça :-).
        
        Ben il a pas tord dans le sens ou ecrire du code generique est:
        1) super dur. Juste parce que ca compile ne veut pas dire que c'est une bonne api.
        2) au final plutot rare. Sorti des trucs de bases de la lib (collection, etc.)
        3) indicatif d'un gros probleme de design/approche (ca c'est mon avis personnelle). Le code "generique" releve de la philosophie "one size fits all", le st graal de beaucoup de developeurs qui pensent pouvoir resoudre tous les problemes du monde avec une solution.
        Au final (et c'est toujours mon avis), tu te retrouves avec une solution qui reponds mal a tous les problemes, avec une complexite qui explose. T'as vachement mieux fait d'utiliser d'une part des interfaces/protocoles (regarde ce qu'objc fait par exemple, ca te fait du code "generique" vachement plus efficace et clair), ou tout simplement ecrire du code specifique a ton domaine (ce qui ira plus vite, marchera mieux et sera bien simple a comprendre).
        
        Bref, effectivement, la feature est en plein dans la philosophie du c++ et c'est bien la le probleme - c'est ce que voulait dire l'OP je pense. Un immense bordel de feature, impossible a apprehender par un humain sans des annees de pratiques, avec de nombreuses facons de tirer dans le pied, et sans porte de sortie.
        Encore une fois, regardes ce qu'objective c fait, un langage objet plutot elegant qui n'a pas a palir face a c++, et qui peut etre apprehende dans sa totalite par a peu pres tout le monde (et qui se traine effectivement certaines casseroles historiques, certes, mais c++ aussi, comme tout langages au final).
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: Syntaxe étonnante
      
      Posté par rewind (Mastodon) le 26 mai 2014 à 09:26. Évalué à 7.
      
      Beaucoup de projets font volontairement le choix d'utiliser qu'un sous-ensemble plus ou moins restreint du langage, pour que la barrière d'entré reste relativement basse.
      
      Ce n'est pas spécifique à C++11, ça a toujours été comme ça avec C++. Regarde Qt par exemple.
      
      Je souhaite d’ailleurs bien du courage à ceux qui vont implémenter ce genre d’éléments dans le compilateur, parce que dans le genre syntaxe qui pète tout, on est pas mal.
      
      C'est déjà implémenté depuis bien longtemps dans les deux compilateurs du monde libre.
      
      Et non, ce n'est pas un troll, le C++ est beaucoup trop gros et sa courbe d'apprentissage ne fait que s'élever de norme en norme.
      
      Il n'est pas trop gros, il offre des possibilités. Tu peux apprendre à faire du C++ en à peu près 2h pour les fonctionnalités de base indispensable. Après, tu peux découvrir ses possibilités pendant 10 ans, et être étonné tous les jours d'en apprendre encore. Ces possibilités sont des opportunités pour améliorer ta productivité dans ce langage, mais tu peux aussi rester avec les fonctionnalités de base, c'est au choix.
      - [^] # Re: Syntaxe étonnante
        
        Posté par Antoine le 27 mai 2014 à 13:18. Évalué à 4.
        
        Tu peux apprendre à faire du C++ en à peu près 2h pour les fonctionnalités de base indispensable. Après, tu peux découvrir ses possibilités pendant 10 ans, et être étonné tous les jours d'en apprendre encore. Ces possibilités sont des opportunités pour améliorer ta productivité dans ce langage, mais tu peux aussi rester avec les fonctionnalités de base, c'est au choix.
        
        Comme d'habitude, le problème n'est pas quand on fait des pâtés tout seul dans son coin, mais quand on interagit avec des projets existants, vu qu'il faut bien se familiariser avec les idiomes utilisés (et pour peu que le projet ait un certain âge, ceux-ci risquent d'être multiples et d'épuiser toute la gamme des possibilités offertes par le langage).
        
        Je pense que les normalisateurs du C++ gagneraient à définir un sous-ensemble "safe C++" ou "modern C++" qui constituerait une baseline devenant à terme l'idiome dominant et recommandé par la communauté (avec éventuellement des flags de compilation ou des pragmas pour alerter le développeur quand du code sort de ce sous-ensemble).
        
        [^] # Re: Syntaxe étonnante
        
        Posté par rewind (Mastodon) le 27 mai 2014 à 13:37. Évalué à 4.
        
        C'est quoi l'intérêt de développer avec un langage atrophié ? Vraiment, c'est idiot. On ne va pas s'interdire d'utiliser une fonctionnalité offerte par un langage au prétexte qu'il existe quelqu'un qui ne la comprends pas. J'ai envie de dire que c'est une bonne façon d'apprendre quelque chose de nouveau. Sans compter que je pense que ça serait difficile de déterminer ce sous-ensemble pour plusieurs raisons : la première est que la bibliothèque standard utilise une grosse partie des fonctionnalités de C++, est-ce que tu interdis les parties de bibliothèque standard qui utilisent les trucs en dehors du sous-ensemble ? la seconde, c'est que dès que tu vas tirer un morceau, le reste va venir avec. Les templates par exemple tirent quasiment toutes les nouveautés de C++11. Et si tu te refuses à utiliser les lambdas alors que ça simplifie la lecture, et bien je dirais que c'est très dommage.
        
        Il y a deux parties qui peuvent être évitées : le RTTI et les exceptions. Mais ça, c'est pas nouveau et il y a déjà des flags pour ça depuis des années.
        
        [^] # Re: Syntaxe étonnante
        
        Posté par David Demelier (site web personnel) le 27 mai 2014 à 14:02. Évalué à 2. Dernière modification le 27 mai 2014 à 14:04.
        
        Il y a deux parties qui peuvent être évitées : le RTTI et les exceptions. Mais ça, c'est pas nouveau et il y a déjà des flags pour ça depuis des années.
        
        Est-ce que tu parles des options de compilation qui permettent de désactiver RTTI et les exceptions ?
        
        Je suis assez d'accord pour RTTI mais enlever les exceptions est vraiment dommage, d'ailleurs est-ce que c'est réellement possible ? à part noexcept j'ai jamais trouvé d'options de compilation pour les désactiver.
        
        git is great because linus did it, mercurial is better because he didn't
        
        [^] # Re: Syntaxe étonnante
        
        Posté par Troy McClure (site web personnel) le 27 mai 2014 à 14:40. Évalué à 2.
        
        Perso j'ai plutot l'avis opposé je suis d'accord pour les exceptions mais pas trop pour le RTTI.
        
        -fno-exceptions pour les virer avec gcc , par defaut elles ne sont pas activées avec visual c++ ( il faut mettre /EHsc )
        
        LLVM se passe des deux, on dirait: http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions
        
        [^] # Re: Syntaxe étonnante
        
        Posté par Anthony Jaguenaud le 27 mai 2014 à 15:41. Évalué à 2.
        
        LLVM se passe des deux, …
        
        La bonne phrase serait : LLVM conseille de se passer des deux.
        Personnellement j'utilise un peu les deux. Les exceptions car je trouve pratique de renvoyer void plutôt qu'un code d'erreur à redescendre de 5 ou 10 appels de fonctions pour prendre une décision, et le dynamic_cast. C'est d'ailleurs le seul RTTI que j'utilise.
        
        [^] # Re: Syntaxe étonnante
        
        Posté par flan (site web personnel) le 28 mai 2014 à 22:09. Évalué à 5.
        
        Je suis tout à fait d'accord, c'est un peu le même problème que les GOTO : si c'est dans le langage, c'est qu'on peut les utiliser sans remord (mais ce n'est pas pour ça qu'il faut en mettre à toutes les sauces !).
        
        J'ai une petite expérience en Python, et ça m'arrive régulièrement de reprendre (ou relire) du code externe.
        Ça arrive d'avoir des syntaxes que je ne connaissais pas (par exemple [int(x) for x in [0, 2] if x != 1] ), mais je n'ai à peu près jamais eu de problème de compréhension.
        
        Là, avec une expérience équivalente en C++, je pense que je serais totalement largué dans du code externe qui jongle avec un peu tous les nouveaux aspects du C++. C'est quand même un inconvénient.
        
        [^] # Re: Syntaxe étonnante
        
        Posté par Batchyx le 28 mai 2014 à 17:57. Évalué à 5.
        
        C++ est un langage généraliste et l'a toujours été. Tout le monde n'a pas besoin de toutes les fonctionnalités. Typiquement du calcul numérique bourrin n'a aucun besoin d'exceptions ou d'orienté objet mais va aimer les lambdas (et les templates pour les utiliser). Quelqu'un qui fait du réseau va aimer les exceptions et le RAII. mais n'a pas forcement besoin d'orienté objet ou de templates. Quelqu'un qui fait une application bureautique va avoir d'autres besoin …
    - [^] # Re: Syntaxe étonnante
      
      Posté par Guillaume Denry (site web personnel) le 26 mai 2014 à 10:41. Évalué à 3. Dernière modification le 26 mai 2014 à 10:42.
      
      Mais comment voulez vous que des programmeurs apprennent et aient en tête les mille et une fonctionnalités du langage ?
      
      Bin c'est simple, on le veut pas :) (si je me place hypothétiquement dans le "vous" de ta question)
      Pourquoi un langage devrait être connu de fond en comble pour pouvoir être utilisé ? Tu ne connais probablement pas toutes les subtilités de la langue française, ça ne t'empêche pas d'être parfaitement capable de t'exprimer en langage soutenu.
      Après, c'est un point de vue assez naïf, et je sais bien que cette approche comporte au moins un risque majeur : transformer le C++ en espèce de tour de Babel où un programmeur, par exemple, orienté "template" deviendrait incapable d'être bien compris par un développeur qui n'en utilise jamais. C'est pour ça qu'il serait bien commode de pouvoir introduire une sorte de terminologie pour bien distinguer des domaines de compétences au sein de C++, afin d'être par exemple utilisé dans des offres d'emploi (ex: "recherche développeur C++/Template").
    - [^] # Re: Syntaxe étonnante
      
      Posté par Lutin le 26 mai 2014 à 13:13. Évalué à 4.
      
      Pour ma part j'ai rayé C++ de mon CV.
      - [^] # Re: Syntaxe étonnante
        
        Posté par G.bleu (site web personnel) le 26 mai 2014 à 16:51. Évalué à 2.
        
        C'est ennuyeux quand on voit sur quoi pointe ta page perso ;-)….
        
        [^] # Re: Syntaxe étonnante
        
        Posté par Lutin le 26 mai 2014 à 17:20. Évalué à 3.
        
        C'est du C++ très basique ce projet, carrément du C with Classes.
    - [^] # Re: Syntaxe étonnante
      
      Posté par flan (site web personnel) le 26 mai 2014 à 21:12. Évalué à 5.
      
      Je suis assez d'accord. Au final, on obtient un langage qui sera maîtrisé par de moins en moins de monde.
      Sur le fond, c'est cool d'avoir toutes ces fonctions, mais si c'est pour qu'il n'y ait que deux tondus et trois pelés qui sachent s'en servir, c'est bien dommage. J'attends beaucoup des nouvelles générations de langages (genre Rust), pour avoir quelque chose de relativement simple à apprendre tout en ayant les avantages du C++.
    - [^] # Re: Syntaxe étonnante
      
      Posté par Batchyx le 26 mai 2014 à 22:30. Évalué à 10.
      
      Ça m'énerve, les nouveautés du C++11 ne font que complexifier le langage plus qu'autre chose.
      
      Si tu trouve C++03 plus simple que C++11, c'est parce que tu n'en a pas fait assez. Parce que avant que C++11 ou que Boost existe, il y avait de quoi criser.
      
      Quand en C++11 tu déplace tes objets, en C++03 tu émule ça avec de la copie de pointeurs ce qui fait que ton programme est une gigantesque soupe de pointeurs qui ne demande qu'a leaker ou à planter si tu à oublié de mettre à jour ce pointeur là dans un coin. Ajoute des programmeurs inexpérimentés et/ou un problème compliqué à résoudre et c'est comme ça qu'on se retrouve avec des monstres que personne ne peut maintenir. J'ai même pas besoin de citer une suite bureautique ou un navigateur web qui était dans ce cas là, vous savez très bien de quoi je parle.
      
      Et on peut en citer d'autres: combien de redéfinitions se sont transformés en surcharges sans aucun warning de la part du compilateur ? Combien de programmeurs se sont fait avoir par le parsage de de C++ qui transforme des appels de fonctions en déclarations sans effets ? Combien de réimplementations buggées de pointeurs partagés avec comptage de références ? Combien de boucles chiantes avec un typedef et deux iterateurs juste pour parcourir un vecteur ?
      
      Si tu n'a pas passé assez de temps à te battre contre ton compilateur, contre des leaks ou contre tes collègues, c'est sûr que tu ne comprendra jamais pourquoi les concepteurs de C++ ont décidé d'écouter la communauté de programmeurs C++ et d'améliorer considérablement leur quotidien.
      
      Mais comment voulez vous que des programmeurs apprennent et aient en tête les mille et une fonctionnalités du langage ?
      
      On pourrai dire la même chose de tout les langages modernes. Et même les langages qui n'évoluent pas (comme C) ont leur usages qui se complexifient. On est plus en 1990. On ne peut plus se dire programmeur C et ne pas savoir utiliser des pointeurs sur fonctions.
      
      Beaucoup de projets font volontairement le choix d'utiliser qu'un sous-ensemble plus ou moins restreint du langage, pour que la barrière d'entré reste relativement basse.
      
      Des règles similaires existent même pour du code C, c'est juste qu'elles ne sont souvent pas écrites. les projets GTK n'autorisent pas le même code que le noyau Linux.
      
      J'ai l'impression qu'ils (les auteurs de la norme C++11) essayent de faire des mécanismes pour obtenir du code ultra-générique mais ne se rendent pas compte que la contre partie est très importante.
      
      La généricité dans C++11 ne prend pas une place aussi importante que ce que tu lui donne. la généricité supplémentaire de C++11, c'est les constexpr, les decltype, les paramêtres templates par défaut pour les méthodes et les static_asserts. Ce n'est qu'une petite partie de C++11. Même encore aujourd'hui, la plupart du code générique que j'écris pouvait déjà être fait en C++03.
      
      C++11, c'est aussi auto, les foreach, les override/final, les regex, les threads, les déplacements, les pointeurs intelligents, et plein d'autres fonctionnalités qui ne rendent pas ton code plus générique mais qui rendent le langage bien plus agréable à utiliser.
      
      D'une part, le besoin de faire un code générique ne se rencontre que rarement, et d'autre part, ont perd souvent beaucoup en lisibilité et simplicité.
      
      en C c'est pareil: on à jamais absolument besoin de séparer son code en fonctions indépendantes. Et quand on le fait, on perd en simplicité, on augmente le nombre de ligne et il faut naviguer dans plusieurs fonctions pour savoir ce que le code fait. Et en plus c'est souvent inutile vu que la plupart des fonctions ne sont appelées qu'à un seul endroit dans le code.
      
      Mais bon sang, c'est quand même bien plus maintenable comme ça. Séparer en fonction me garanti que le code qui gère la base de donnée ne va pas interférer avec le code qui gère le réseau. Ça permet d'en prendre des bouts et de les réutiliser ailleurs.
      
      La généricité en C++11 c'est pareil. Si je sais que mon code générique se contente de passer une valeur sans savoir ce que c'est, je suis sûr qu'elle n'y touchera pas. Ça permet d'apporter bien plus de garanties et de lisibilité à ce que mon programme fait. Et si j'applique ça à tout mon code, alors mon code ne sera qu'un ensemble de briques indépendantes que j'ai assemblé d'une certaine façon pour répondre à un besoin particulier.
      
      Alors oui on peut coder à la mode des années 1980, en C sans utiliser de pointeurs, ça sera sans doute plus simple à comprendre pour des étudiants, mais dès que le programme se complexifiera un peu, il n'y aura guerre que l'auteur original pour y comprendre encore quelque chose.
    - [^] # Re: Syntaxe étonnante
      
      Posté par arnaudus le 28 mai 2014 à 16:09. Évalué à 4.
      
      Ça m'énerve, les nouveautés du C++11 ne font que complexifier le langage plus qu'autre chose.
      
      J'ai un peu le même sentiment. C++ évolue vers un outil destiné à un petit groupe de professionnels très qualifiés. C'était déja un peu le cas, mais c'est de pire en pire : on voit nettement apparaitre des développeurs de bibliothèques (qui vont utiliser les template, les génériques, les deftypes et les lambdas, etc) et les utilisateurs. Finalement, est-ce qu'on n'aurait pas le même genre de structures pour beaucoup d'outils, comme Latex par exemple, où 99% des utilisateurs sont infoutus de comprendre le contenu d'un fichier de style?
      
      Le problème, c'est que les êtres humains étant ce qu'ils sont, les gens ne vont pas s'empêcher de tenter d'épater la gallerie avec du code complexe là où il n'est pas nécessaire. C++ offre finalement trop de possibilités. Qui n'a jamais vu une classe string surcharger les opérateurs + et += pour faire de la concaténation, par exemple? Finalement, ces possibilités de programmation générique vont principalement servir pour étendre la STL ou autres trucs très très conceptuels, mais pas pour le code de tous les jours. Ce qui me gène le plus, c'est la perte totale de l'autodocumentation.
      - [^] # Re: Syntaxe étonnante
        
        Posté par Astaoth le 29 mai 2014 à 15:16. Évalué à 2.
        
        Quand tu codes, tu n'es pas obligé d'utiliser toutes les nouveautés qui complexifient la syntaxe.
        
        Emacs le fait depuis 30 ans.
        
        [^] # Re: Syntaxe étonnante
        
        Posté par arnaudus le 29 mai 2014 à 19:18. Évalué à 6.
        
        Non, mais ça n'est pas ça le problème. Le problème principal c'est de comprendre le code. Prend un projet libre par exemple. Si la base du code est écrite par un développeur professionnel, il risque de coder comme lui le peut, c'est à dire d'utiliser toutes les subtilités du langage. Si le code est écrit par un amateur éclairé, c'est presque pire, car il risque lui aussi d'utiliser tout ça, mais mal. Le truc, c'est qu'après, il faut que d'autres puissent lire le code, le comprendre, l'auditer, et corriger les bugs. Si tu réduis drastiquement le nombre de gens sur Terre qui peuvent comprendre ton code, tu réduis aussi la taille de ta communauté.
        
        La question se pose donc à plusieurs niveaux. Il est évident que les nouveautés ont un intérêt, sinon elles n'auraient jamais été mises en place. Certaines sont vraiment bénéfiques pour la lisibilité (les types auto, par exemple), mais d'autres sont complètement obscures (les lambdas, etc), et sont sont réservées qu'aux développeurs de bibliothèques génériques.
        
        L'autre problème, c'est que C++ offre de plus en plus de manières différentes de faire la même chose, avec des subtilités évidemment, mais quand même. Et de plus en plus de manières de faire de mauvais choix d'interface, ce qui rejoint l'idée qu'il s'oriente vers une sorte d'élitisme.
    - [^] # Re: Syntaxe étonnante
      
      Posté par jean-michel.bertrou.eu le 29 mai 2014 à 16:00. Évalué à -2.
      
      Ce que tu dis n'est pas faux, mais il faut bien voir qu'il faut de tout pour faire un monde de programmation : des gens qui sont contents d'avoir dans leur boite à outils le choix entre plein de types de pointeurs différents, et d'autres pour qui "Less Is More".
      
      Je crois qu'il faut être tolérant et ne pas forcer les gens à utiliser des outils qui ne cadrent pas à leur psychologie.
      - [^] # Re: Syntaxe étonnante
        
        Posté par needs le 30 mai 2014 à 00:22. Évalué à 4.
        
        Je suis d'accord avec toi quand il s'agit de projets personnels. Mais dès que tu as une équipe qui bosse dessus, tu dois garder un code cohérent et maintenable. Tu devras forcer certaines personnes à faire des choses qu'elles n'ont pas l'habitude de faire. Je n'ai encore jamais vu de projet suffisamment gros qui ne cadre pas le champs des possibilités du langage utilisé.
  - [^] # Re: Syntaxe étonnante
    
    Posté par Anthony Jaguenaud le 26 mai 2014 à 15:45. Évalué à 5. Dernière modification le 26 mai 2014 à 15:45.
    Au lieu d'écrire :
```
template<class T, class U>
auto add(T t, U u) -> decltype(t + u);
```
    Ne peut-on pas écrire :
```
template<class T, class U>
decltype(t + u) add(T t, U u);
```
    Ajout avant validation :
    En prévisualisant le commentaire, j'ai compris. Les paramètres de la fonction t et u ne sont pas encore déclarés. Je le laisse juste au cas où quelqu'un d'autre se pose la même question. Ca explique l'intérêt de la nouvelle manière de déclarer des fonctions.
# Merci pour les références

Posté par robin le 26 mai 2014 à 00:47. Évalué à 7.

Merci pour les références, c’était très instructif. J’avais suivi attentivement le développement du C++11, mais je me rends compte que certains concepts m’avaient échappés. En tout cas, plus le temps passe plus j’aime ce langage !

bépo powered

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.