vendredi 30 juillet

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Développeur

[95] Du côté de chez Xorg
[66] Les technos web cools du moment
[30] OsmocomBB : Pour un GSM complètement libre !
[24] Drupal 7.0 alpha 1 est sortie
[4] Venez jouer avec playframework
[67] Sortie de Qt 4.6
[1] Nuit de l'info 2009
[35] Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc)
[113] Go : Un nouveau langage chez Google
[33] Formation JAVA : + de 100 tutoriaux progressifs pour s'auto-former

Liens connexes

Annonce sur le blog d'Herb Sutter (194 clics)
Retard dans la norme (128 clics)
Présentation de C++0xB sur wikipedia (870 clics)

Dépêche modérée par

NoNo

Dépêche éditée par

Développeur : C++ 0xB enfin finalisé ?

Posté par GeneralZod (). Modéré le 15 mars 2010.

Herb Sutter annonce sur son blog que le comité ISO C++ a voté l'ébauche finale de la nouvelle norme du langage.

À partir de maintenant, seules les corrections mineures pourront être effectuées et Herb Sutter estime que la version finale sortira en 2011.
La norme ayant été élaborée en collaboration proche avec les implémenteurs, la plupart des compilateurs sur le marché ont intégré partiellement la nouvelle norme, certains ajouts à la bibliothèque standard bénéficient même d'une implémentation dans la célèbre collection de bibliothèques Boost dans un espace de nom distinct.

Annonce sur le blog d'Herb Sutter (194 clics)
Retard dans la norme (128 clics)
Présentation de C++0xB sur wikipedia (870 clics)

> Lire la suite (42 commentaires, moyenne: 3,5). [dépêche : 1736 caractères]

Après le retrait des concepts qui devaient faciliter le développement des templates dû à la complexité d'implémentation, quelques petits changements :

Retrait de la fonctionnalité "export template", le seul compilateur intégrant celle-ci étant Comeau et quasiment personne ne l'utilise, il a été décidé de la supprimer pour soulager la tâche des implémenteurs ;
Ajout du mot clé "noexcept" pour compléter la dépréciation des déclarations d'exceptions. Cela devrait aider le compilateur à effectuer certaines optimisations.

C++0xB apporte une syntaxe simplifiée :

Fini le petit espace entre les deux chevrons fermants quand on imbrique deux classes génériques. Amélioration mineure, mais appréciable ;
Les fonctions lambda (appelées closures dans certains langages) qui devraient profiter, entre autres, à l'utilisation des algorithmes et des bibliothèques de traitements parallèles comme Intel TBB ;
Les listes d'initialisations pour les conteneurs ;
Boucle type foreach ;
Union non restreinte aux types POD ;
Prise en charge d'unicode ;
etc.

Mais également un enrichissement de la bibliothèque standard :

Nouveaux conteneurs : tuples, tables de hachages ;
Pointeurs habiles (type Boost) ;
Expressions rationnelles, threads, etc.

Pour la petite anecdote, C++0xB devait sortir dans la première décennie du troisième millénaire, mais au vu des retards, il a été suggéré avec humour d'utiliser une notation hexadécimale.

Il est probable que le nom final de la norme soit tout simplement C++11.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

C++, un langage moderne ?

Posté par Bruno Michel (page perso, ) le 15/03/2010 à 21:50. (lien). Évalué à 6.

Encore un peu et le C++ pourrait devenir un langage moderne. Prise en charge d'unicode, fonctions lambda et Regexp dans la bibliothèque standard, je pense que ça m'aurait fait à l'époque où je faisais du C++. Depuis, j'ai essayé un paquet d'autres langages, et je n'ai jamais eu envie de revenir au C++, et je doute forte que ce soit une nouvelle révision par décennie qui me fasse changer d'avis (je trouve le moratoire de 2 ans de Python déjà bien assez long comme ça).

[^]Re: C++, un langage moderne ?

Posté par Graveen () le 15/03/2010 à 22:00. (lien). Évalué à 7.
j'étais en train de penser la même chose... et le foreach()....

à l'énorme détail prés que ce genre de révision me donne envie d'y revenir (ou de me me réorienter dessus, plutôt).

C++ c'est quand même... bah C++ quoi !

--
Sauvez un arbre: mangez un castor.
- [^]Re: C++, un langage moderne ?
  
  Posté par Tonton Benoit (Jabber id, ) le 16/03/2010 à 00:31. (lien). Évalué à 3.
  foreach est déjà implantée via des macros dans Qt4, Boost et même la STL je crois.
  Mais son implémentation au niveau du langage est une bonne chose, ça fera moins bidouille et sera peut-être un peu plus performant. J'espère juste que la syntaxe sera proche de celle utilisé par Qt, elle est bien foutue et ça me fera moins de travail pour le portage :p
  - [^]Re: C++, un langage moderne ?
    
    Posté par GeneralZod () le 16/03/2010 à 00:51. (lien). Évalué à 4.
    Le foreach est basé sur celui de Boost et le concept d'intervalles, ça supporte les tableaux, listes d'initialisations, conteneurs, etc ... La principale différence est qu'on réutilise le mot clé for.
  - [^]Re: C++, un langage moderne ?
    
    Posté par LupusMic (page perso, ) le 18/03/2010 à 02:27. (lien). Évalué à 1.
    Je ne comprends pas pourquoi std::for_each n'est pas suffisant ?
    - [^]Re: C++, un langage moderne ?
      
      Posté par Troy McClure (page perso, ) le 18/03/2010 à 09:13. (lien). Évalué à 2.
      je dirais parce que c'est moche et verbeux et pas pratique.
      - [^]Re: C++, un langage moderne ?
        
        Posté par whity () le 18/03/2010 à 09:38. (lien). Évalué à 2.
        Ca change beaucoup avec les expressions lambdas (le côté pas pratique).
        
        Après, moche et verbeux ?
        
        std::for_each(list.begin(), list.end(), f);
        
        Pour comparaison, en C#
        
        foreach(T item in list) f(item);
        
        Pas une grosse différence. On pourrait certes faire mieux avec des range plutôt que des itérateurs, mais la STL ne les a pas, alors on fait sans. Et côté approche, cela me semble nettement plus propre que l'approche C# (qui en plus, introduisait au départ des downcasts à tire-larigot du fait de l'implémentation de l'interface IEnumerable).
        
        Le BOOST_FOREACH a l'avantage de permettre de mettre du code entre { }, et l'inconvénient, comme toute macro, de déconner grave avec les templates.
        
        [^]Re: C++, un langage moderne ?
        
        Posté par Troy McClure (page perso, ) le 18/03/2010 à 09:52. (lien). Évalué à 5.
        En effet les lambda devraient bien aider. Mais je continue à trouver for_each moche et tout pourri (en plus d'etre triviallement debile). J'aime les bonnes vieilles boucles, celles dans lequelle l'action effectuée est ecrite entre de bonnes vielles accolades et est juste un bon vieux bloc de code, sans chichis autour. Repeter les .begin() et .end() alors que 99% du temps je parcours tous les elements du conteneur moi ça me fait braire, j'ai vraiment horreur des trucs redondants.

[^]Re: C++, un langage moderne ?

Posté par Fabimaru! (Jabber id, page perso, ) le 15/03/2010 à 22:24. (lien). Évalué à 1.
Des regexp oui! Des expressions rationnelles oui! Mais pas pas d'expression régulières s'il vous plait!

--
Pas de bureau 3d libre sans drivers libres!
- [^]Re: C++, un langage moderne ?
  
  Posté par Bruno Michel (page perso, ) le 15/03/2010 à 22:58. (lien). Évalué à 2.
  Bien vu, je corrige ça dans la dépêche.
- [^]Re: C++, un langage moderne ?
  
  Posté par GeneralZod () le 15/03/2010 à 23:00. (lien). Évalué à 10.
  J'ai pendant longtemps parlé d'expressions rationnelles, mais on m'a récemment convaincu qu'expression régulière n'était pas forcément un anglicisme.
  Une expression régulière est une expression qui obéit à certaines règles de construction, c'est correct en Français et c'est finalement bien plus proche du terme original.
- [^]Re: C++, un langage moderne ?
  
  Posté par Axioplase ıɥs∀ (page perso, ) le 18/03/2010 à 09:54. (lien). Évalué à 3.
  « Closure » en français scientifique, se traduit de deux manières :
  - « clôture » quand on parle de la clôture transitive d'une relation ;
  - « fermeture » quand on parle d'un pointeur de code avec un environnement (ce qui est présentement le cas).
  
  Alors « les fonctions lambda (appelées closures dans certains langages) » c'est ignoble à lire, même si l'anglais est bien un langage…
  Merci de corriger ça aussi…
  
  (Et encore… déjà que « fonction lambda » c'est pas terrible…)
  
  --
  Je ne suis pas toujours de mon avis.
  - [^]Re: C++, un langage moderne ?
    
    Posté par Antoine () le 18/03/2010 à 20:22. (lien). Évalué à 2.
    Sans compter qu'une "fonction lambda" (c'est-à-dire une fonction anonyme), ce n'est pas forcément une fermeture et vice-versa.
  - [^]Re: C++, un langage moderne ?
    
    Posté par Yusei () le 19/03/2010 à 11:05. (lien). Évalué à 2.
    J'ai toujours entendu parler de fermeture transitive, et jamais de clôture transitive.
  - [^]Re: C++, un langage moderne ?
    
    Posté par LupusMic (page perso, ) le 19/03/2010 à 18:14. (lien). Évalué à 1.
    « Fermeture » n'est franchement pas une traduction intelligente. Elle dénote un peu plus le manque de maîtrise de l'anglais par nous autres, pauvres informaticiens. Le terme « closure » fait plus référence à la proximité (I am close to you), plutôt qu'à la fermeture. Ce qui est logique, puisque le principe des closures, c'est de maintenir des références (et non des pointeurs) vers les variables déclarées dans la portée où a eu lieu la déclaration de la fonction. Ce qui nous ramène bien au concept de proximité.
    - [^]Re: C++, un langage moderne ?
      
      Posté par Axioplase ıɥs∀ (page perso, ) le 21/03/2010 à 08:33. (lien). Évalué à 3.
      C'est aussi une structure avec un pointeur de code qui renferme l'environnement nécessaire à l'exécution du code selon la sémantique voulue.
      
      Je ne vois pas la proximité. J'y vois justement plus la fermeture (non transitive) de l'environnement.
      
      --
      Je ne suis pas toujours de mon avis.
      - [^]Re: C++, un langage moderne ?
        
        Posté par LupusMic (page perso, ) le 22/03/2010 à 14:35. (lien). Évalué à 1.
        Et moi je ne vois pas le rapport avec la choucroute. Les closures concernent l'accès à des variables issues d'une portée différente. Je ne vois pas ce que vient faire un outil d'algorithmie de calcul des chemins.
        
        Je pense que tu es plus avancé que moi en mathématique. Du coup, tu donnes un autre sens au mot « fermeture », et donc tu n'es pas choqué par son emploi pour les closures. Alors que pour moi, une fermeture, ça reste un loquet, une tirette, une poignée de porte, etc.

[^]Re: C++, un langage moderne ?

Posté par defmonkey () le 16/03/2010 à 12:02. (lien). Évalué à 5.
«Encore un peu et le C++ pourrait devenir un langage moderne. Prise en charge d'unicode, fonctions lambda et Regexp dans la bibliothèque standard, je pense que ça m'aurait fait à l'époque où je faisais du C++.»

Bof, tout ça (ou presque) existe depuis bien longtemps. Pas dans la bibliothèque standard, mais dans des bibliothèques (Boost, PCRE, etc.) qui sont disponibles depuis fort longtemps. Note aussi que les regexp sont dans l'API C Posix depuis moultes temps déjà (man regex).

«je trouve le moratoire de 2 ans de Python déjà bien assez long comme ça»

En ce qui concerne l'évolution des langages, je dois dire que c'est vraiment le contraire que j'affectionne: la stabilité. L'évolution permanente me semble plus relever de l'aveu (mon langage est mal b...) que de l'innovation.
Oui à l'évolution des bibliothèques standards quand des manques flagrants se font sentir (le réseau en Lisp, par ex ;), non à l'évolution permanente des langages.

[^]Re: C++, un langage moderne ?

Posté par Barret Michel (Jabber id, page perso, ) le 16/03/2010 à 16:51. (lien). Évalué à 6.
Les langages qui évoluent tout les 2 ou 3 ans je trouve que c'est une faiblesse. Construire un langage c'est avoir une vision au moins à moyen terme. Changer de norme continuellement c'est, d'après moi, une preuve de fragilité.

--
Debian Squeeze
- [^]Re: C++, un langage moderne ?
  
  Posté par Bruno Michel (page perso, ) le 16/03/2010 à 20:32. (lien). Évalué à 6.
  Certes, construire un langage, c'est avoir une vision à moyen/long terme, mais aucun langage n'est parfait, ni même n'a atteint un état vraiment satisfaisant (ce n'est peut être pas vrai pour des langages spécialisés, mais pour les langages généralistes accompagnés de leur bibliothèque standard, ça me semble évident). Du coup, devoir attendre des années et des années pour voir évoluer un langage me semble complètement inapproprié.
  
  Je vais prendre un exemple : « Fini le petit espace entre les deux chevrons fermants quand on imbrique deux classes génériques. » Ça me semble aberrant que l'on ait du attendre 10 ans (sûrement plus, en fait) pour corriger ça. Quand je pense au nombre de développeurs qui ont oublié cette espace et qui n'ont qu'un message d'erreur totalement incompréhensible, perdant pas la même occasion un bon paquet d'heures, c'est vraiment un gaspillage incroyable.
  - [^]Re: C++, un langage moderne ?
    
    Posté par NanoTech () le 16/03/2010 à 23:32. (lien). Évalué à 5.
    En effet, car il s'agit d'un changement sans conséquence de rétro-incompatibilité.
    Par contre, les changements à la python sont beaucoup plus gênants, parce qu'ils changent la signification du code silencieusement (même aux mises à jour mineures), et que ça ne peut se révéler que dans des cas de code rarement exécuté, du coup, on risque de ne même pas voir de Warning durant les deux ans de transition.
    Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3). Dès que plusieurs projets ou librairies doivent interagir, c'est le cauchemar.
    
    Pour la programmation système, je suis toujours fan du C90. Au moins, ça compile partout sans incompatibilité artificielle.
    - [^]Re: C++, un langage moderne ?
      
      Posté par Antoine () le 18/03/2010 à 20:28. (lien). Évalué à 3.
      Par contre, les changements à la python sont beaucoup plus gênants, parce qu'ils changent la signification du code silencieusement (même aux mises à jour mineures)
      
      Même aux mises à jour mineures ? Tu as un exemple ?
      
      Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3)
      
      Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
      Au contraire, forker est assez propre dans la mesure où cela signale bien la rupture de compatibilité.
      - [^]Re: C++, un langage moderne ?
        
        Posté par NanoTech () le 21/03/2010 à 11:21. (lien). Évalué à 2.
        Même aux mises à jour mineures ? Tu as un exemple ?
        
        À toutes les versions, il y a un changelog très bien fait.
        
        Même immédiatement après une mise à jour majeure, des changements rétro-incompatibles sont faits:
        Par exemple, le changement des règles de visibilité des variables dans python 2.1:
        http://docs.python.org/whatsnew/2.1.html#pep-227-nested-scop(...)
        Les autres versions aussi ont fait des changements incompatibles.
        
        2.6 a supprimé les exceptions chaîne de caractères.
        2.5 à supprimé la possibilité de renvoyer None dans __reduce__ (module pickle).
        2.4 a changé le module email de telle sorte qu'aucune exception n'est lancée en cas de message mal formé parce qu'il ne décode pas tout d'un coup, mais utilise maintenant l'attribut defect pour signaler les erreurs au moment où il les rencontrent...
        2.2 a changé la règle de recherche des méthodes en cas d'héritage multiple avec problème du diamant.
        
        Ces incompatibilités touchent habituellement très peu de code, mais, à cause de la nature dynamique du langage, et de la subtilité des modifications, elles peuvent être silencieuses. Par exemple, un filtre de mailing list chargé de vérifier la validité des messages va silencieusement ignorer les erreurs à la 2.4.
        
        Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
        
        C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles. C'est pire que la division perl/ruby/python parce que ces langages étant clairement incompatibles, les communautés sont mieux séparées et on ne risque pas de mélanger du code accidentellement, vu qu'ils ont un syntaxe très différente.
        
        La migration au 3 ne fournissant aucun retour sur investissement, les entreprises ne la feront qu'à contrecoeur, et uniquement quand la nécessité sans fera sentir.
        
        On pourrait espérer que python 3 a supprimé d'un seul coup tout ce qu'il y avait de "mauvais" dans python 2.x, mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:
        http://docs.python.org/dev/3.0/whatsnew/3.0.html#pep-3101-a-(...)
        En fait, il semblerait qu'un bon rythme de dépréciation/suppression soit retenu pour python 3.x.
        
        Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
        
        Sans compter le dilemme pour les nouveaux programmeurs: 2.x (plus large base installée, plus de librairies) ou 3.x (l'avenir, en théorie), mais on a pas toujours le choix (dépendance d'un librairie d'une tierce partie).
        
        [^]Re: C++, un langage moderne ?
        
        Posté par Antoine () le 21/03/2010 à 16:10. (lien). Évalué à 2.
        Par exemple, le changement des règles de visibilité des variables dans python 2.1
        
        Pour moi Python 2.1 n'est pas une version mineure, c'est une version majeure.
        Par version mineure, j'entends par exemple le passage de la 2.6.4 à la 2.6.5.
        
        C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles.
        
        Je ne vois rien de tel dans la communauté, justement. Les similitudes sont assez grandes entre 2.x et 3.x pour que les gens continuent à échanger sans souci.
        
        mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:
        
        C'est un cas particulier. La nouvelle syntaxe de formatage de chaîne est un serpent de mer. Au début il était en effet prévu que l'ancienne meure totalement, mais cela a été repoussé aux calendes grecques.
        
        Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
        
        Je ne pense pas, non. C'est un choix délibérément fait, pour introduire une version du langage plus agréable à utiliser. C'est aussi parce que la base d'utilisateurs n'est pas sous-estimée que le choix a été fait de ne pas repartir depuis zéro, mais simplement de faire les modifications les plus importantes. Les connaissances nécessaires pour développer avec la 2.x ou la 3.x ne sont pas significativement différentes, on s'en sort très bien en pratique.
        
        Du reste, si la tendance continue, la base d'utilisateurs sera encore plus grande d'ici quelques années, lorsque (on l'espère) les versions 3.2/3.3 seront devenues les versions de choix pour développer.

D'autres gros ajouts

Posté par Etienne () le 16/03/2010 à 06:21. (lien). Évalué à 9.

Il y a plusieurs autres ajouts qui sont importants :
- La gestion des threads dans le langage et la bibliothèque standard
- Les variadic templates qui doivent rendre des choses comme boost::mpl ou les typelist de Loki beaucoup plus simple.
- Les rvalue reference qui permettent de "déplacer" un objet dans un autre et, par exemple, éviter une copie du type de retour et permettre ainsi de retourner un objet non copiable.

Et pas mal d'autres choses, l'article de wikipedia en anglais est plus fournit que celui en français (http://en.wikipedia.org/wiki/C%2B%2B0x )

Étienne

[^]Re: D'autres gros ajouts

Posté par Troy McClure (page perso, ) le 16/03/2010 à 12:37. (lien). Évalué à 7.
Je me demande si la possibilité de maitriser toutes les subtilités du c++0x est encore à la portée d'un être humain
- [^]Re: D'autres gros ajouts
  
  Posté par whity () le 16/03/2010 à 13:09. (lien). Évalué à 6.
  Tu peux enlever le 0x. Maîtriser toutes les subtilité du C++ est déjà hors de portée d'un être humain.
  
  Mais ça n'empêche absolument pas de l'utiliser au jour le jour, puisqu'on a rarement besoin de toutes ces petites subtilités (et que, non, ces subtilités ne jouent pas contre nous si on ne s'en sert pas).
  - [^]Re: D'autres gros ajouts
    
    Posté par Guillaume Knispel () le 16/03/2010 à 13:53. (lien). Évalué à 4.
    Si tu n'utilise que du code que tu écris toi-même ou que tu valides chaque bibliothèque pendant 3j avant de t'en servir, ton raisonnement se tient :P
- [^]Re: D'autres gros ajouts
  
  Posté par alice_liddell () le 16/03/2010 à 14:00. (lien). Évalué à 6.
  Ce qui est hors de portée des êtres humains, c'est les templates avancées (comme on les trouve dans boost). Cette évolution permet justement de réduire fortement la complexité de ces templates.
  
  Je regrette juste deux choses :
  
  - l'abandon des 'concepts' qui aurait énormément simplifier le langage.
  - rien n'est fait pour remplacer l'antique couple entête / #include par un système moderne de modules.
  - [^]Re: D'autres gros ajouts
    
    Posté par Barret Michel (Jabber id, page perso, ) le 16/03/2010 à 16:53. (lien). Évalué à 4.
    Je suis d'accord sur l'abandon des concepts. Pour les "includes" ça viens de la compatibilité avec le C.
    
    --
    Debian Squeeze
    - [^]Re: D'autres gros ajouts
      
      Posté par Troy McClure (page perso, ) le 16/03/2010 à 18:58. (lien). Évalué à 4.
      Et puis se debarasser du preprocesseur c'est pas facile on finit par s'y attacher à ce truc.
      - [^]Re: D'autres gros ajouts
        
        Posté par Gniarf () le 17/03/2010 à 11:22. (lien). Évalué à 3.
        t'es pas obligé de te séparer de la notion de préprocesseur, et même au contraire, c'est souvent fort utile. je m'en servais en... Java.
        
        --
        The greatest trick the Google Devil ever pulled was convincing the world he did no evil.
        
        [^]Re: D'autres gros ajouts
        
        Posté par lasher () le 17/03/2010 à 18:01. (lien). Évalué à 2.
        T'es pas le premier que je lis/j'entends dire ça, tiens.
        
        [^]Re: D'autres gros ajouts
        
        Posté par Guillaume Knispel () le 23/03/2010 à 02:24. (lien). Évalué à 1.
        Ça me parait un peu indispensable pour éviter de devenir totalement cinglé de garder une capacité de calculs à la construction, fût-elle primitive comme ce qu'offre le préprocesseur C ou C++.
        Aussi utile pour faire les transformations syntaxiques fort utiles si les langages imposent une syntaxe lourde (ex : manque de littéraux)
    - [^]Re: D'autres gros ajouts
      
      Posté par Sytoka Modon (page perso, ) le 16/03/2010 à 23:30. (lien). Évalué à 2.
      Enfin, le C pourrait lui aussi évoluer sur ce sujet ;-)
  - [^]Re: D'autres gros ajouts
    
    Posté par whity () le 17/03/2010 à 09:31. (lien). Évalué à 2.
    Je ne crois pas que les concepts auraient simplifié le langage. Ils auraient simplifié l'utilisation de template, en permettant aux compilateurs de sortir des messages d'erreur clairs.
    
    Mais ils auraient aussi complexifié l'écriture de ces templates (pas grave, c'est le boulot des développeurs de librairie, qui ont un niveau technique dans le langage supérieur à la moyenne), et surtout, ils entraînaient une énorme complexification des compilateurs.
    
    Les développeurs vont devoir continuer d'apprendre à lire les messages d'erreur de leur compilateur, qui cela dit ont énormément progressé depuis et sont maintenant relativement utilisables.
    
    Pour les modules, je crois qu'on peut rêver : vu le succès qu'a eu export, c'est mort. C pourrait probablement le faire, mais pour C++ et son système de templates, l'expérience a prouvé que ça apportait plus de mal qu'autre chose. Et il y a tellement de code existant qui a besoin du préprocesseur, les développeurs y sont tellement habitués, que ça n'a guère d'intérêt.
    - [^]Re: D'autres gros ajouts
      
      Posté par Etienne () le 17/03/2010 à 09:42. (lien). Évalué à 2.
      Les développeurs vont devoir continuer d'apprendre à lire les messages d'erreur de leur compilateur, qui cela dit ont énormément progressé depuis et sont maintenant relativement utilisables.
      
      Normalement, dans la prochaine de version de GCC (4.5) les messages d'erreurs n'afficheront plus les paramètres template par défaut (cf http://gcc.gnu.org/gcc-4.5/changes.html : When printing the name of a class template specialization, G++ will now omit any template arguments which come from default template arguments.)
      
      Étienne
    - [^]Re: D'autres gros ajouts
      
      Posté par alice_liddell () le 17/03/2010 à 10:07. (lien). Évalué à 2.
      <q>Pour les modules, je crois qu'on peut rêver : vu le succès qu'a eu export, c'est mort. C pourrait probablement le faire, mais pour C++ et son système de templates, l'expérience a prouvé que ça apportait plus de mal qu'autre chose. Et il y a tellement de code existant qui a besoin du préprocesseur, les développeurs y sont tellement habitués, que ça n'a guère d'intérêt.</q>
      
      Il ne faut pas forcément remplacer le préprocesseur, mais le système est une horreur et on est obligé d'utiliser tout un tas de techniques (pimpl, forward declaration dans tous les sens, classes virtuelles pures, factory) même pour des classes simples dès qu'on veut faire une API propre.
      - [^]Re: D'autres gros ajouts
        
        Posté par whity () le 17/03/2010 à 10:57. (lien). Évalué à 1.
        Il ne faut pas forcément remplacer le préprocesseur, mais le système est une horreur et on est obligé d'utiliser tout un tas de techniques (pimpl, forward declaration dans tous les sens, classes virtuelles pures, factory) même pour des classes simples dès qu'on veut faire une API propre.
        
        Tu peux détailler un peu ? Parce que personnellement, je n'ai pas de problèmes avec ça (sauf, dans une certaine mesure, les forward declaration. Mais souvent, s'il y a trop de forward declarations, c'est qu'il y a trop d'interdépendances --> peut-être que la conception est à revoir ?)
        
        Les classes virtuelles pure, la factory, ça relève du design (pImpl aussi d'ailleurs, quoique c'est plus discutable). Ca n'a rien à voir avec la "propreté" de l'API que tu exposes. La seule chose que je vois qui pourrait manquer à un développeur habitué à java ou csharp, c'est la notion de "package" et la visibilité "internal". Mais je suis dubitatif sur son intérêt (C++ a friend pour les cas où c'est utile).
        
        [^]Re: D'autres gros ajouts
        
        Posté par alice_liddell () le 17/03/2010 à 15:52. (lien). Évalué à 2.
        Deux exemples :
        
        - on ne peut pas ajouter une variable membre privée à une classe sans casser la compatibilité binaire.
        - si les types des membres privés viennent d'une bibliothèque, l'utilisateur de ma classe doit posséder les entêtes cette bibliothèque.
        
        On peut toujours s'en sortir et un bon design permet d'éviter ces problèmes.
        
        Mais c'est assez pénible au quotidien.
        
        [^]Re: D'autres gros ajouts
        
        Posté par whity () le 18/03/2010 à 09:01. (lien). Évalué à 0.
        - on ne peut pas ajouter une variable membre privée à une classe sans casser la compatibilité binaire.
        
        Je comprends mieux pourquoi tu parlais de pimpl. Effectivement, on ne peut pas changer la taille d'un objet sans casser la compatibilité binaire, sauf à ce que les clients n'utilisent que des pointeurs vers ces objets (auquel cas, rajouter un membre à la fin ne casse rien). C'est un peu le lot de tous les langages compilés, cela dit...
        
        - si les types des membres privés viennent d'une bibliothèque, l'utilisateur de ma classe doit posséder les entêtes cette bibliothèque.
        
        Ca dépend, là aussi, si les types sont inclus tels quels, oui, si ce sont des références ou des pointeurs, une forward declaration suffit. C'est toujours le même problème de taille d'objet, qui doit être connue pour tout module utilisant l'objet.
        
        Je ne crois pas qu'il y ait de solution à ce problème (celle de java/c# n'en est pas une, c'est vraiment une approche différente).
        
        Après, tout dépend du contexte. Personnellement, ça n'a jamais été un problème (forcer tous les utilisateurs de mon code à recompiler n'a jamais été une grosse contrainte, ça l'est par contre pour celui qui fait des bibliothèques).
        
        [^]Re: D'autres gros ajouts
        
        Posté par alice_liddell () le 18/03/2010 à 12:10. (lien). Évalué à 4.
        C'est un peu le lot de tous les langages compilés, cela dit...
        
        Sauf Objective C, Java, C# et probablement d'autres.

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : C++ 0xB enfin finalisé ?

C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

[^]Re: C++, un langage moderne ?

D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts

[^]Re: D'autres gros ajouts