Dans la course effrénée que se livrent les compilateurs, GCC vient traîtreusement de gagner une manche en étant le premier à fournir une implémentation complète du langage C++11. Les développeurs ont profité de la sortie de la version de maintenance 4.8.1 pour implanter les deux fonctionnalités manquantes :
les rvalue-references pour le pointeur this
Celles-ci permettent (entre autres) de surcharger des fonctions membres quand this est une rvalue ; voici un exemple tiré de la proposition originale :
class X {
std::vector<char> data_;
public:
// ...
std::vector<char> const & data() const & { return data_; }
std::vector<char> && data() && { return data_; }
};
X f();
// ...
X x;
std::vector<char> a = x.data(); // copie du vector
std::vector<char> b = f().data(); // move du vector
l'utilisation de decltype sur des expressions de type incomplet
La limitation de decltype à des types complets posait des problèmes d'instanciation de template en cascade. Ce changement a notamment bénéficié aux bibliothèques boost qui ont du coup changé le comportement de leur result_of pour s'aligner sur le comportement de std::result_of.
L'annonce de cette sortie semble être destinée a couper l'herbe sous le pied de LLVM 3.3 dont la publication est imminente.
Toutefois, il s'agira tout-de-même d'une victoire en demi-teinte puisque la libstdc++ de GCC ne fournit toujours pas certains composants de la bibliothèque standard, telles les expressions rationnelles. La libc++ du projet LLVM est déjà complète, ce qui devrait faire de LLVM 3.3 le premier compilateur à prendre en charge le standard C++11 dans sa totalité (langage + bibliothèque standard).
# Troll : merci Apple
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 06 juin 2013 à 23:01.
Sans Apple et le sponsoring de LLVM (troll 2 : qui en plus offre plus de liberté aux développeurs), pas sûr que la vitesse aurait été aussi rapide.
Par contre, mettre de nouvelles fonctionnalités dans une version de maintenance, fallait vraiment vouloir battre symboliquement le concurrent…
[^] # Re: Troll : merci Apple
Posté par rewind (Mastodon) . Évalué à 10.
Apple a sponsorisé au départ, mais maintenant, même si Apple garde la main sur le projet, LLVM est bien tiré par ARM ou Google. En 2012, il y a eu plus de 160 développeurs différents qui ont contribué à LLVM et plus de 130 sur Clang. Je ne pense pas qu'ils soient tous payés par Apple. LLVM/Clang est passé sur un mode de développement proche de celui du kernel, je dirais. C'est sans doute grâce à la licence-qui-accorde-tout-plein-de-libertés ;)
[^] # Re: Troll : merci Apple
Posté par superna (site web personnel) . Évalué à 1.
Pour ARM, apple utilise LLVM pour compiler tout son système et bientôt toutes les applications par défaut !
Jusqu'à présent, Google ne s'en sers pas autant !
Donc oui Apple pousse surtout le support ARM…
[^] # Re: Troll : merci Apple
Posté par groumly . Évalué à 0.
Ils poussent aussi sur x86, clang est le compilo par defaut sur tous les pomme os depuis 2 ans deja.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
# il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par robin . Évalué à 7.
Je viens de vérifier, il maque tout de même le support du garbage collecteur :
"Minimal support for garbage collection and reachability-based leak detection N2670 : No"
avancement de gcc
Néanmoins avec les pointeurs intelligents je doute que le c++ ait vraiment besoin de cette fonctionnalité.
bépo powered
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par small_duck (site web personnel) . Évalué à 2.
Tout à fait. Depuis l'apparition en standard des std::unique_ptr et des std::shared_ptr, je n'ai pas encore rencontré de cas où j'aurais eu envie d'un ramasse-miettes. Cela me semble très à l'opposé des principes du langage, très déterministe, très RAII, et un poil TOC sur les bords avec la mémoire. Mais bon, c'est comme les singletons: ce n'est pas parce que c'est possible qu'une bonne base de code doit l'utiliser.
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par CrEv (site web personnel) . Évalué à 2.
Oué enfin ce qui serait vraiment bien c'est plutôt une fonctionnalité du type Automatic Reference Counting comme il y a en Objective-C.
Là ce serait vraiment intéressant. Les bénéfices de ne pas avoir de garbage collector, par ex en perf, et le fait de ne pas avoir à s'en préoccuper.
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par robin . Évalué à 6.
Quelle est la différence réelle avec un shared pointeur ? (ormis le fait de devoir écrire shared_pointeur).
bépo powered
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par CrEv (site web personnel) . Évalué à 0.
Faudrait demander à un dev mac/ios moi je sais que ça existe mais je ne l'ai jamais vraiment utilisé ;-) Par contre les connaissances que j'ai qui ont fait pas mal de C++ et qui font maintenant de l'Obj-C sont vraiment contentes de ce point.
Mais je dirais que l'un des bon points c'est surtout que tu ne t'en occupes plus du tout.
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par VinDuv . Évalué à 3.
Le concept de shared_ptr ne serait pas applicable en ObjC, notamment parce que le langage ne permet pas d’allouer des objets sur la pile (uniquement sur le tas, comme en Java). Donc forcément, ça marche un peu différemment… En Objective-C, la gestion de la mémoire se fait à l’aide d’un compteur de référence (intégré aux objets), qui était jusqu’ici géré manuellement par les développeurs, et qui maintenant est géré automatiquement par ARC (en gros ARC fait le travail des développeurs en rajoutant des appels aux méthodes de gestion du compteur de référence là où c’est nécessaire)
La compatibilité d’un code compilé avec ARC avec du code "classique" est complète (sous réserve que le code classique en question gère correctement la mémoire…), donc ça facilite les migrations (on peut même le faire fichier par fichier). Alors que pour passer d’un code C++ qui fait des new/delete à des shared_ptr, il doit falloir plus de boulot d’un coup…
Je pense aussi que ARC doit pouvoir gérer la mémoire plus finement que les shared_ptr, parce que C++ impose que les objets alloués sur la pile soient détruits seulement lorsqu’il ne sont plus accessibles (donc généralement à la fin de la méthode/fonction). Donc si un objet temporaire est alloué via un shared_ptr au début d’une fonction, il ne sera libéré qu’à la fin, même si il ne sert à rien entre-temps. ARC, en revanche, peut décrémenter le compteur de référence d’un objet dès qu’il n’est plus utilisé.
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par robin . Évalué à 2.
Merci pour l'explication de l'objective c c'est très instructif.
Pour ce qui est de la gestion de la durée de vie en c++, on peux toujours mettre des accolade aux milieux d'une fonction, de manière a limiter la durée de vie au bloc de portée.
bépo powered
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par psychoslave__ (site web personnel) . Évalué à 10.
Y a un moment faut se décider, tu dis ramasse-miettes ou garbage collector, mais faut arrêter les infâmes mélanges. J’ai rien contre les emprunts qui viennent combler un manque avéré d’une langue, mais faudrait voir à ne pas tomber dans la brouillasse linguistique par simple flemme de chercher les termes idoines existants dans chaque langue.
# gcc et llvm
Posté par robin . Évalué à 1.
J'avoue que j'utilise exclusivement gcc pour mes projets perso, et je ne me suis pas trop intéressé au reste du monde. Je code en c++ et éventuellement en c.
J'ai vu que llvm étais également un projet open source, et il pourrais donc me convenir. Mon futur métier étant l'embarqué, c'est toujours une bonne chose de connaitre plusieurs compilateurs. Selon vous, quels sont les avantages et les défauts de ces deux compilateurs.
bépo powered
[^] # Re: gcc et llvm
Posté par Lutin . Évalué à 2.
N'ayant aucune main sur le truc qu'on installe sur les produits vendus, j'utilise LLVM principalement LLVM quand j'ai un peu de temps en rab', on a parfois des warnings très différents, c'est toujours intéressant de jeter un œil dessus.
[^] # Re: gcc et llvm
Posté par Renault (site web personnel) . Évalué à 10.
Comme c'est souvent dit dans les bons livres de programmation (dont ceux de Rob Pike et de Kernighan), plus une application est portée ou testé sur des compilateurs, architectures ou OS différents, plus il est robuste en mettant en évidence les particularité de chacun qui doit être traité proprement afin d'être le plus portable et agnostique qu'il soit.
Cela permet également de corriger des bogues insoupçonnés car non mis en évidence par la seule solution testée en prime abord…
[^] # Re: gcc et llvm
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Sans aller jusqu’à nier le gros de ce constat, il faut aussi voir que plus d’archi/compilo, c’est aussi plus de bugs spécifiques à gérer qui te font ajouter tout un tas de casseroles de contournement qui nuisent à la factorisation de ton code.
[^] # Re: gcc et llvm
Posté par Renault (site web personnel) . Évalué à 7.
L'objectif c'est de modulariser au mieux ton programme.
En effet, pouvoir être utilisable sur tous ces différents cas, il est nécessaire de travailler à encapsuler proprement le code pour séparer ce qui est générique et spécifique à chaque configuration. Cela isole les problèmes et permet de réaliser un éventuel portage supplémentaire bien plus vite car seule la partie spécifique sera à écrire, et la partie commune sera bien plus robuste aux particularités de chacun qui peuvent interférer.
Le livre dont j'ai mentionné les auteurs a expliqué que le portage a une autre application leur a permis de travailler de ce côté. Le port du noyau Linux sur une autre architecture a permis de nettoyer et réorganiser le code de sorte à faciliter les portages et diminuer la quantité de bogue spécifique à chaque. Les bogues éventuellement ajouter par ce travail est plus simple à régler car elle doit se situer dans la partie spécifique alors qu'éventuellement dans un code mal organisé il peut s'infiltrer un peu partout et pour peu que le projet soit grand il serait difficile de le corriger.
[^] # Re: gcc et llvm
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Je ne dis pas que ça ne peut pas aider à mettre un coups pied aux fesses et inciter à utiliser de saines pratiques. Cela étant il ne faut pas aller jusqu’à en déduire une relation causale, les développeurs peuvent tout aussi bien décider de faire des ifdef sauvages un peu partout au milieu de leur bouillasse de goto.
[^] # Re: gcc et llvm
Posté par NilugeKiWi . Évalué à 3.
Des erreurs plus lisibles sur clang, et quelques checks/warnings en plus: j'utilise les 2.
Cependant les dernières versions de gcc ont l'air d'avoir amélioré la lisibilité si j'ai bien compris.
Clang permet de faire de l'autocomplétion aussi: https://github.com/Golevka/emacs-clang-complete-async
Je n'ai pas encore croisé d'équivalent avec gcc.
[^] # Re: gcc et llvm
Posté par Shuba . Évalué à 4.
Pareil, j'utilise les deux, clang compile mon code en debug (messages d'erreur plus clairs, meilleur temps de compilation) et gcc pour l'optimisation (je n'ai cependant pas encore fait de tests de performance, mais on lit beaucoup que gcc génère encore du meilleur code que clang).
L'autocomplétion de clang existe aussi pour vim, très agréable à utiliser.
[^] # Re: gcc et llvm
Posté par Krunch (site web personnel) . Évalué à 2.
De ce que j'en entend, un gros intérêt de LLVM est qu'il permet d'écrire des outils de manipulation de code et d'analyse statique de manière bien plus facile qu'avec GCC.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# On s'y met!
Posté par small_duck (site web personnel) . Évalué à 9. Dernière modification le 06 juin 2013 à 23:23.
J'ai convaincu mon employeur de passer à C++11, et c'est très plaisant d'utiliser les listes d'initialisation, les variables auto, et bien sûr la sémantique de déplacement. Le gain de performances lors de la redimension de vecteurs de pointeurs partagés est impressionnant.
C'est une nouvelle vie pour le langage, et ça me donne une bonne excuse pour passer du temps sur les nouveaux Guru of the Week d'Herb Sutter.
[^] # Re: On s'y met!
Posté par Thom (site web personnel) . Évalué à 1. Dernière modification le 07 juin 2013 à 08:09.
C'est vrai que auto, c'est pas mal quand tu veux te passer d'écrire des :
(Merci pour le lien de ce site que je ne connaissais pas)
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# Meilleurs erreurs
Posté par Thom (site web personnel) . Évalué à 1.
Personnellement, ce que j'aimerai également avec gcc c'est qu'il me renvoie des erreurs de compilation un poil plus lisibles… mais après (Trolldi) c'est propre au C++ de lâcher des erreurs aussi moche pour faire un tri sur les développeurs et ne prendre que ceux qui de toutes façon ne les lisent pas.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Meilleurs erreurs
Posté par robin . Évalué à 1.
En même temps comment veux tu obtenir le sentiment de supériorité et d’estime de sa toute puissance, lorsqu’on se rend compte que « ça y est un message de quatre lignes d’erreur ne me fait plus peur ».
À titre d’anecdote, il me semble que mon record est de 10 lignes ˁ˚ᴥ˚ˀ avec des templates bien chiadé avec gcc !
Une petite question, est ce que mes smiley en ascii art un utf8 sont lisibles sous Windows ? (à cause de l’encodage)
bépo powered
[^] # Re: Meilleurs erreurs
Posté par Batchyx . Évalué à 3.
C++11 avait initialement prévu l'introduction de concepts pour justement éviter les messages d'erreurs à rallonge lorsqu'on utilise des templates avec des types qui respectent pas les concepts demandés. Mais ça à été abandonné pour que C++11 sorte en 2011.
C++14 prévoit des concepts simplifiés.
[^] # Re: Meilleurs erreurs
Posté par nazcafan . Évalué à 4.
J'étais à une conférence de Bjarne il y a un mois ou deux. D'après ce qu'il a dit, les «concepts lite» feraient mieux de s'appeler « concepts done right ». Visiblement le nouveau truc dépote carrément : on a plus des temps de compilation 20 fois supérieurs à « sans concepts » (ils sont maintenant du même ordre) et la spec est passée de plus de 50 pages à 7 ou 8 pages dans le standard.
Ce sera peut-être un tout petit peu moins puissant mais au moins, ça marche (je crois qu'ils font joujou avec une branche expérimentale de clang pour les tests).
Quelques pistes d'information à ce sujet sur stack overflow
[^] # Re: Meilleurs erreurs
Posté par claudex . Évalué à 3.
C'est justement une des améliorations de GCC 4.8
« 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: Meilleurs erreurs
Posté par nazcafan . Évalué à 2.
Anéfé,
le capitalismela concurrence a eu du bon et certains diagnostics affreux de g++ ont été progressivement corrigés (un grand classique était l'oubli du «;» après une définition de classe qui provoquait une erreur des centaines de lignes plus bas). Le wiki de GCC a même une page dédiée qui montre qu'ils ont sérieusement rattrapé clang sur beaucoup de points.[^] # Re: Meilleurs erreurs
Posté par rewind (Mastodon) . Évalué à 2.
Sur les erreurs, Clang restera meilleur que GCC sur un point : les erreurs liés aux macros. Quand une erreur est dû à une macro, GCC donne uniquement la ligne de l'instantiation de la macro, pas la ligne à l'intérieur de la macro. Clang lui est capable de donner la ligne de la macro concerné. Et comme je ne suis pas très clair, je vais donner un exemple.
Avec gcc 4.7.3 :
Avec clang 3.0 :
Et ça, GCC ne pourra jamais le faire, à moins de revoir profondément son architecture. GCC appelle le préprocesseur dans un processus à part (comme toutes les étapes de la compilation) et donc perd les informations précises dans ce cas tandis que Clang fait toute la compilation dans un seul processus, lui permettant de suivre les informations.
On pourrait faire le même genre d'exemple avec l'assembleur inline.
[^] # Re: Meilleurs erreurs
Posté par khivapia . Évalué à 5. Dernière modification le 07 juin 2013 à 16:11.
Et ça, GCC ne pourra jamais le faire, à moins de revoir profondément son architecture. GCC appelle le préprocesseur dans un processus à part (comme toutes les étapes de la compilation) et donc perd les informations précises dans ce cas tandis que Clang fait toute la compilation dans un seul processus, lui permettant de suivre les informations.
On pourrait faire le même genre d'exemple avec l'assembleur inline.
Si ce n'est que les infos sur le contenu des macros sont transférées jusqu'au binaire final au moment de l'assemblage quand on compile avec les symboles de débuggage au niveau -g3. Elles sont donc forcément accessibles quelque part :)
[^] # Re: Meilleurs erreurs
Posté par Gof (site web personnel) . Évalué à 10. Dernière modification le 07 juin 2013 à 16:29.
Il faut croire que l'architecture de GCC a été revue profondément avec gcc 4.8 alors:
# Y'a que moi que ça choque?
Posté par Maclag . Évalué à 7.
Ce serait un petit projet, je ne dirais rien, mais le truc utilisé de par le monde pour des projets somme toute assez critique, ils y rajoutent des nouvelles fonctionnalités dans les versions de maintenance??
[^] # Re: Y'a que moi que ça choque?
Posté par Gof (site web personnel) . Évalué à 9.
On peux dire que la non conformité à une spécification est un bug. Non?
# Pendant ce temps à Vera Cruz
Posté par calandoa . Évalué à 10.
« Lorsque votre seul outil est le C++, tous les clous ressemblent à des pouces »
[^] # Re: Pendant ce temps à Vera Cruz
Posté par ariasuni . Évalué à 1.
Pas compris la référence… Quelqu’un pour me dégrotter?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pendant ce temps à Vera Cruz
Posté par Renault (site web personnel) . Évalué à 5.
Pendant ce temps à Vera Cruz est une référence au film « La cité de la peur », pour signaler que pendant l'action qui se déroule sous les projecteurs il y a aussi des activités plus banales en parallèle ailleurs.
La citation sur le C++ est une référence au fait que le C++ est un langage tellement complexe et casse gueule qu'en tant qu'outils il fait autant voire plus de dégât qu'il n'en résout (tout comme un marteau qui taperait plutôt sur les doigts que sur les clous).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.