La nouvelle mouture de C++, devrait être publiée en 2010 ou 2011 Les concepts, attendus par beaucoup de développeurs, devaient permettre, entre autres, de réduire l'importante verbosité des erreurs de compilation lors de l'utilisation de classes template (notamment les conteneurs de la bibliothèque standard C++). Auparavant, le compilateur devait remonter toute la couche d'appels dans l'implémentation du conteneur, qui devenait alors visible au développeur. Les concepts devaient alors permettre de lever l'erreur beaucoup plus tôt. Un exemple est donné sur le site de la branche «concepts» de C++ :
http://www.generic-programming.org/software/ConceptGCC/
Évidemment, les concepts, c'est beaucoup plus qu'un compilateur moins verbeux. Il s'agit aussi d'une garantie sur le type générique utilisé dans une classe template et les amateurs de programmation générique se frottaient déjà les mains.
Malheureusement, de sérieux problèmes se sont mis sur la route du comité de normalisation. Un problème technique, lié aux concepts implicites, pouvant gêner l'utilisateur, d'abord, et surtout le fait que les développements des principales implantations des concepts (notamment gcc) sont au point mort.
Plusieurs décisions étaient envisageables, comme attendre encore 5 ans avant d'avoir un nouveau standard, ou bien sortir les concepts tels quels (et prendre le risque qu'ils passent à la trappe, comme le mot clé "export" du C++98). Il a été finalement décidé de les retirer pour ne pas impacter les autres changements tant attendus.
C++1x est actuellement partiellement pris en charge par plusieurs compilateurs. Du côté du « core language », on peut suivre l'évolution de la prise en charge par gcc sur la page suivante :
http://gcc.gnu.org/projects/cxx0x.html
Les aventureux pourront tester les nouveautés en ajoutant l'option «-std=c++0x» à l'invocation du compilateur.
La Nemesis de gcc, Visual Studio, n'est pas en reste et propose elle aussi une prise en charge, probablement présentée dans le lien suivant (video silverlight que je n'ai pas pu lire) :
http://www.microsoft.com/france/vision/mstechdays09/Webcast.(...)
Chez intel, un début de prise en charge :
http://www.intel.com/software/products/compilers/docs/clin/m(...)
Au niveau de la prise en charge des nouveautés de la bibliothèque standard, (TR1) on peut noter les avancées de gcc ici :
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.(...)
Il est tout à fait possible d'utiliser les classes de TR1 avec le standard C++ actuel en préfixant l'inclusion des headers par TR1. Les classes seront alors dans l'espace de nommage std::tr1. L'utilisation de l'option «-std=c++0x» permet de s'affranchir de ces formalités.
Dinkumware, fournisseur officiel de la bibliothèque standard C++ à la sauce visual, revendique quant à lui une prise en charge complète du TR1 :
http://www.dinkumware.com/tr1_compare.aspx
Les concepts mis à part, la prise en charge du nouveau standard par les principaux compilateurs est donc en bonne voie, ce qui est un atout majeur pour l'adoption de C++1x.
Aller plus loin
- problèmes avec les concepts (12 clics)
- Stroustrup sur la solution adoptée (10 clics)
- le TR1 sur la wikipedia anglaise (7 clics)
- C++1x sur la wikipedia anglaise (19 clics)
- La page Wikipedia sur les concepts C++ (11 clics)
# Traduction de claim
Posté par Fnor . Évalué à 10.
Il me semble que revendique est une meilleur traduction du mot anglais claim.
# Un standard kikoo-lol ou obfuscisant ?
Posté par saucisson . Évalué à 2.
Ca fera plaisir aux industriels, puisqu'ils pourront enfin se mettre à pisser du code du standard précédent.
Ca fera plaisir aux noobs qui pourront mettre du "auto" partout, de la même manière qu'ils ne savent pas utiliser correctement un "const" actuellement.
Ca va faire plaisir aux gourous qui aiment coder des générateurs de code à coup de templates.
Ca va faire plaisir aux brainfuckers avec une syntaxe encore plus ambiguë.
Ca va faire plaisir aux adorateurs de performance puisqu'ils pourront encore supprimer des copies inutiles en rendant leur code illisible.
Et pour les développeurs ? Ceux qui doivent réaliser un produit qui fonctionne à peur près ? Ah ben pour eux, non. Emmerdez-vous avec des pages et des pages d'erreurs.
Arriver à obtenir des messages d'erreur clairs ? Vous pouvez rêver !
Arriver à débugger du code imbitable écrit par un faux gourou passé avant ? Ahah, on va rire avec les subtilités ajoutées !
Pourquoi se faire encore chier avec un langage dans une impasse évolutive ? Il y a d'autres langages... non ? D ? Ada (qui certes ne permet pas de metaprog) ? Des vrais langages pensés pour être utilisés, et non pour permettre à des spécialistes de mépriser le commun des mortels pour leur ignorance, et se faire faire de gros chèques.
Mais qu'attendons-nous pour faire grève dès qu'il faut toucher à cette bouse infâme ?!
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par nazcafan . Évalué à 10.
Déjà, l'inclusion de certaines classes est vitale, comme les unordered_xxx, qui n'avaient pas pu être incluses en 98 faute de temps.
Ensuite, la plupart des nouveautés sont faites pour améliorer la lisibilité du code et la facilité de développement:
le mot clé que tu décries tant va permettre d'éliminer une verbosité pénible, sachant que la plupart du temps, il va servir à changer une ligne comme :
for(typename mon_conteneur_au_nom_bien_long::const_iterator it= v.begin();v!=v.end();++it)
en
for(auto it= v.begin();v!=v.end();++it)
Donc, bien utilisé, il n'apporte aucune ambiguïté.
Un autre exemple, la délégation de constructeurs, venue de langages comme Java, va permettre d'éviter énormément de redondances avec des listes d'initialisation énormes à maintenir.
Dernier exemple : les lambda expressions, qui n'a jamais pesté de devoir définir une fonction complètement triviale, pour l'inclure dans un for_each() 300 lignes plus bas ? L'ajout de cette feature permettra d'autant d'augmenter la lisibilité du code.
Alors, que le langage devienne plus complexe, peut-être, mais les améliorations vont quand même dans le sens d'une lisibilité plus grande, d'une écriture plus coulante et d'une maintenance moins coûteuse.
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par windu.2b . Évalué à 3.
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par nazcafan . Évalué à 9.
Mettons que tu aies 3 attributs à initialiser dans ta classe, tu crées un constructeur qui prend 3 arguments et tu t'en sers pour initialiser.
Jusqu'ici, aucune différence,
Si tu veux créer un second constructeur en Java, tu peux très bien créer un constructeur qui va se contenter d'appeler le premier avec des arguments codés en dur, alors qu'en C++, tu vas devoir les initialiser les attributs à la main.
En plus, mettons que du dois rajouter un attribut, et que tu mets à jour le premier constructeur, mais pas le second. Dans le premier cas, le compilo râle, alors que dans le second, ça devrait passer, et tu te retrouves avec un attribut mal initialisé. Le monde peut alors commencer à s'écrouler
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par barmic . Évalué à 1.
Dommage tout de même pour les concepts…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Laurent Morel . Évalué à 3.
Pourtant sur le fond je rejoins 'saucisson' : C++ est une accumulation de règles complexes destinées à clarifier ou contourner les problèmes posés par les règles précédentes.
J'avoue, j'ai arrêté le C++ après avoir lu "que seules les personnes en charge de la spécification du langage pouvaient connaître toutes ses arcanes" (en substance).
Effectivement, peu de personnes dans le monde sont capables d'écrire du vrai C++ en comprenant TOUT ce qu'elles écrivent (il y a un piège à chaque point-virgule).
Pour avoir relu du code générique écrit par un vrai "C++ guru", ben... j'ai parcouru, demandé moults explications, puis simplement commenté : "Très (trop ?) bon niveau de codage" : franchement, ce n'était pas maintenable par un mortel normal.
Objectivement, je ne trolle pas, mais vous voyez un avenir à C++ pour les terriens ?
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Troy McClure (site web personnel) . Évalué à 10.
Faut juste arriver à passer le plus vite possible le court moment de délire qui se produit quand on comprend la puissance des templates et qu'on essaye de faire executer la moitié du programme par le compilateur :) (en sacrifiant des poulets pour qu'il inline le reste comme il faut)
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par reno . Évalué à 3.
-GC (Boehm-Demers-Weiser) primitif comparé à celui de Java (par exemple)
-bisbilles entre librairie 'standard' incompatibles (Phobos vs Tango), mais ce point la est en cours de résolution.
-pas de compilateur 100% libre (GDC semble mort et la releve pas encore prete).
Bref le langage idéal n'existe pas..
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par reno . Évalué à 5.
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il existe aussi une lib wrapper pour que cela ressemble plus au C mais bon...
"La première sécurité est la liberté"
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par reno . Évalué à 4.
Bah, remplacer 'a + b' par add(a,b) par exemple rendrait un langage plus 'regulier' et plus 'simple' mais *moins* lisible pour moi.
Comme quoi..
>Il existe aussi une lib wrapper pour que cela ressemble plus au C mais bon...
As-tu un lien?
Note que si c'est juste un generateur externe cela n'a pas beaucoup d'interet car ce qui compte c'est la syntaxe 'commune' utilisee par tous.
Si c'est la future syntaxe du language c'est interressant, autrement c'est comme ceux qui faisait du Pascal en C en utilisant le preprocesseur: bof.
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Ontologia (site web personnel) . Évalué à 1.
- if cond:BOOLEAN then true_block:BLOCK :BOOLEAN <-
(
cond.if true_block
);
- while cond:BLOCK do body:BLOCK <-
(
cond.while_do body;
);
Tu peux en inventer des centaines :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par reno . Évalué à 3.
Cela ne resout PAS le chmilblick..
Le probleme numero 1 est la communication entre developpeurs, projets.
Avec un language minimaliste mais souple grace aux macros, chacun souffre et invente ses propre macros plus ou moins bonne --> mauvaise communication.
Pour moi, un bon langage offre donc une syntaxe 'officielle' agreable a utiliser pour les developpeurs: par exemple Scala.
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
list match {
case Nil => Nil
case pivot::tail => qsort(for(i <- tail if i < pivot) yield i) ::: pivot :: qsort(for(i <- tail if i >= pivot) yield i)
}
C'est lisible ça ?
"La première sécurité est la liberté"
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Ontologia (site web personnel) . Évalué à 2.
Tu modifie la librairie standard C++/Java/whatever toi ?
Moi pas, en tout cas.
Donc la syntaxe est "officielle".
2. La syntaxe, tu n'aimes pas c'est ton droit, et je me fais le porte parole de son concepteur :
a) A été mûrement réfléchi par quelqu'un qui a plusieurs centaines de milliers de lignes de code à son actif sur des projets volumineux
b) A intégré assez profondément une réflexion sur le génie logiciel, en particulier celle de Meyer et Eiffel, qu'il cite souvent.
Si tu respecte la lib standard, ce qui est la règle et très très rarement l'exception dans un projet, personne ne peut inventer de macro.
On peut certes inventer des structures de contrôles comme en Ruby, mais uniquement dans les lib du projets.
En passant, en C++, des macro on peut en faire à foison
PS : j'ai rien compris à l'exemple de code fourni en Scala par Nicolas plus bas, et pourtant je me suis intéressé à ce langage, qui me plait en tant que fan de Caml.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Alex . Évalué à 4.
pour moi il a 2 gros défauts, les templates plus ou moin bien gérés selon les compilos, et les itérateurs qui sont "lourds" à écrire
Un autre défaut à mon goût, c'est la stl plutot vieillissante, pour moi c++ doit s'accompagner d'une lib type qt ou boost
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Littleboy . Évalué à 4.
Les iterateurs, avec auto ca simplifie pas mal (c'est juste du sucre syntaxique de toute facon).
Par contre pour la stl vieillissante, je suis pas trop d'accord avec toi. TR1 (deja dispo un peu partout) a apporte quelques nouveautes interessantes et il y a encore pas mal de trucs sympas a venir. Et puis boost a la base, c'est un peu le reservoir a idees pour le standard. La plupart des nouveautes dans la stl de C++1x ont mature dans boost pendant des annees. C'est pas mal comme systeme je trouve, puisque tu met dans le standard quelque chose dont tu es a peu pres sur de l'utilite et des chances d'implementation dans les compilos/stls (export, cough cough!).
Pour QT, je t'avoues que j'ai pas trop d'experience dessus. Ils ont separe la partie GUI et classes de base il y a un petit moment, mais je sais pas si il y a beaucoup de projets qui les utilisent sans utiliser toute la couche GUI. Si tu as besoin d'une classe specifique que tu ne peux pas trouver ailleurs je vois bien l'interet de te baser sur QT, mais sinon pourquoi ne pas utiliser la stl de base direct (ca fait une dependance en moins, c'est toujours ca de gagne)?
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par yellowiscool . Évalué à 3.
Qt, c'est la boite à outils de nokia.
J'ai fait l'erreur pas mal de fois, donc je préfère prévenir maintenant.
Envoyé depuis mon lapin.
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Alex . Évalué à 4.
Bon ensuite j'aime beaucoup qt donc j'en fait beaucoup de pub, (et en toute honnêteté, je n'ai pas réessayer boost depuis quelques années) mais il y a quand même des défauts: preproc obligatoire, pas de multihéritage ou de template héritant de QObject (enfin si, mais par bidouille interposé)
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par Laurent Morel . Évalué à 1.
Concernant les destructeurs, ils n'ont plus lieu d'être si c'est pour libérer la mémoire. Pour les autres ressources (fichiers, etc.), ben vi c'est au programmeur de faire gaffe. Personnellement je n'ai jamais senti le besoin d'un destructeur, ni même vu de destructeurs dans du code java.
Aurais-tu un exemple réaliste ?
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par fearan . Évalué à 1.
Pour coder en C++ depuis quelques années déjà, et dans plusieurs boites différentes, je n'ai jamais eu de soucis à comprendre un morceau de code c++, à la rigueur, un algorithme original pour faire un min sur 10 lignes, mais rien de transcendantal.
Par contre j'utilise les template (j'ai horreur du copier coller) et lorsque c'est pertinent la redéfinition d'opérateur (en général [] ou (), mais parfois + ou - )
le 'type' auto va me simplifier la vie, sans changer fondamentalement ma façon de coder
for ( std::map< int, shared_ptr< PlonkBink > >::const_iterator it = palanque_.begin() ; ...
va considérablement être simplifié
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Un standard kikoo-lol ou obfuscisant ?
Posté par lmg HS (site web personnel) . Évalué à 3.
On ne les aura pas ? Pas grave, STLfilt suffira à 99% des développeurs C++. Le SFINAE servira au 1% (et encore) qui fait de la méta-prog.
En revanche, les ajouts à la bibliothèque standard, l'arrivée des threads et des quelques patterns/facilités qui tournent autour, et des sucres syntaxiques (nullptr, for, >sans espace>, ...) serviront à beaucoup.
Quant à rvalue-references vs COW/expression templates, je me demande bien lequel retourne le plus de l'obfuscation ... Personnellement, j'ai choisi mon camp.
Plus les lambda qui rendront enfin les algorithmes utilisables, au détail que comme en Perl il faudra apprendre à se restreindre.
Quant à la critique "pensé pour être utilisé", c'est justement pour cela que les concepts ont été rejetés : il n'y a aujourd'hui aucune expérience validée de leur utilisation (i.e. un prototype fonctionnel). Ils ne voulaient pas re-commettre l'erreur déjà faite avec les spécifications d'exception ou export.
# Déçu
Posté par ecyrbe . Évalué à 9.
Je programme en C++ sur 90% de mon code... et 10% de C.
Les templates, et particulièrement celles de la Stl, Boost ou gtkmm et consorts génèrent des erreurs difficiles à diagnostiquer.
Avec mon expérience, maintenant je décrypte ces erreurs très vite, mais il m'a fallu accumuler une grosse expérience pour acquérir des automatismes à ce niveau là.
Du coup, quand il s'agit d'embaucher un développeur c++, prendre des débutants est un choix risqué, car je sais que je vais devoir passer énormément de temps à l'encadrer et lui expliquer comment trouver les sources d'erreurs... la productivité s'en retrouve bien vite plombée.
J'attendais donc les concepts avec une grande impatience. même si je suis ravi qu'il y ait l'inclusion du mot clef "auto" et les fonctions "lambda", c'est une fonctionnalité indéniablement utile pour le débutant qui vient de sauter.
ça me laisse un peu perplexe, et encore plus le fait que le standard se voit repoussé.
Le comité de standardisation semble empêtré dans des débats interminable. Ils avancent à une vitesse d'escargot! Les techno c++ commencent à accumuler un retard considérable.
Attendre encore 5 à 7 ans pour voir l'inclusion des concepts dans le c++ me semble être un avis de décès pour ce langage.
J'attends encore un remplaçant convainquant, car D ne m'a pas encore séduit... même s'il a beaucoup d'atouts, il lui manque aussi les concepts et il y a encore trop peu de bibliothèques disponible à mon goût.
Pour faire du code dépendant de la plateforme GLib, j'envisage d'approfondir mon étude de Vala, même s'il n'y a pas de templates mais plutôt des Generics comme en Java. Cependant ce langage est encore trop jeune pour passer en production de mon point de vue.
[^] # Re: Déçu
Posté par ɹǝıʌıʃO . Évalué à 5.
Bon, je te laisse, j'ai du code Objective Caml à écrire.
[^] # Re: Déçu
Posté par ecyrbe . Évalué à 5.
Ocaml répond à certains besoins, mais j'avoue que pondre une interface graphique avec du langage fonctionnel, même s'il supporte des paradigmes impératif est une vrai plaie...
Par contre pour pondre des algorithmes, un compilateur etc... j'avoue qu'ocaml est au dessus du lot!
[^] # Re: Déçu
Posté par ɹǝıʌıʃO . Évalué à 2.
Après lecture des pages de WP données en lien, je ne vois pas ce qu'apportent les concepts que n'a pas OCaml. En résumé, de ce que j'ai compris, un concept permet de vérifier statiquement des contraintes sur une classe, en particulier sur la présence de méthodes avec une signature donnée. Ça ressemble fort à une tentative d'embarquer un langage de modules comme en ont les langages ML, dont Caml (c'est d'ailleurs très pratique).
Quant à ta remarque sur l'interface graphique, j'en écris une en ce moment en gtk, et je ne comprends vraiment pas ce que tu veux dire. J'ai donné en C, je donne actuellement en Caml, et il n'y a pas photo. En C, pour créer la moindre fenêtre avec quelques malheureux contrôles, il faut se farcir des lignes et des lignes qui vont d'une marge à l'autre. En Caml, c'est beaucoup plus concis et donc plus pratique.
[^] # Re: Déçu
Posté par ecyrbe . Évalué à 8.
Mais je n'ai rien contre Ocaml, ce n'est juste pas un remplaçant à c++ à mes yeux.
Quand à ta comparaison Ocaml vs C , on peut dire la même chose C++ vs C
Et je trouve qu"écrire des interface graphiques, des serveurs asynchrones, faire de la programmation parallèle etc, ce n'est pas le fort d'ocaml si on le compare à C++
Ce n'est donc pas une attaque, mais pour le code de mes productions, je ne mettrais jamais de Ocaml. Mais ce n'est que mon point de vue, et peut être ai-je tord.
[^] # Re: Déçu
Posté par loufoque . Évalué à 3.
Un exemple étant Adam & Eve d'Adobe. On pourrait directement écrire en déclaratif en C++ en utilisant un DSEL (et d'ailleurs, certains ont implémenté une version de Eve sous cette forme).
GTK+, Qt, et consorts, c'est bien trop bas niveau.
[^] # Re: Déçu
Posté par ecyrbe . Évalué à 2.
Sinon, Il y a Glade pour Gtk/Gtkmm et le nouveau loadeur GtkBuilder... mais il s'agit plus de RAD que de langage déclaratif ici.
[^] # Re: Déçu
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Déçu
Posté par loufoque . Évalué à 1.
XUL, à la limite, est bien plus proche.
[^] # Re: Déçu
Posté par ecyrbe . Évalué à 4.
Non, ça n'as rien a voir... QtDesigner tout comme Glade, c'est plutôt ce qu'on appelle du RAD (Rapid Application Developpement) avec un système de déclaration des widgets.
Pour voir ce qu'est du Déclarative UI voici un lien vers le projet de Qt :
http://labs.trolltech.com/blogs/category/labs/graphics/kinet(...)
[^] # Re: Déçu
Posté par Ontologia (site web personnel) . Évalué à 1.
En Lisaac, on a essayé de mettre en place une évol permettant de faire tout ce qu'on peut faire avec les templates, sachant que le langage possède à la base la généricité au niveau de l'objet.
ARRAY(E)La nouvelle fonctionalité de la prochaine version du compilo, consiste à permettre de définir des générique au niveau de la méthode.
Je l'ai voulu, car je voulais pouvoir faire ça, dans l'objet ARRAY(E) (ie. tableau du type générique E )
- intersect other : ARRAY(V) with comparator : {E,V;BOOLEAN} <-
(
...
);
Où 'other' est donc une collection contenant un autre type, et 'comparator' la primitive pour l'intersection, ie. fonction prenant E et V en paramètre et renvoyant TRUE si les paramètres sont considérés comme "égaux".
En situation, cela s'utilise comme suit
+ a : ARRAY(FOO);
+ b : ARRAY(BAR);
+ c : ARRAY(FOO);
... a et b sont remplis de diverses choses...
c := a.intersect b with { v1 : FOO ; v2 : BAR ; v1.msg1 = v2.msg2 };
Si je comprend bien (ou peut être que partiellement ?), il s'agirai de pouvoir définir des contraintes sur V ?
En Lisaac, j'imaginerai comme suit, avec la sémantique des contrats disponibles dans ce langage :
- intersect other : ARRAY(V) with comparator {E,V;BOOLEAN} <-
[ -? { + v : V ; v := V.create; v != NULL } ]
(
...
);
Façon moins déclarative de définir que ces exemples http://blog.emmanueldeloget.com/index.php/2008/08/27/136-le-(...) de vérifier qu'on ai bien un constructeur pour V.
Mais en fait, lorsque je lis cela : http://www.devx.com/SpecialReports/Article/38864/0/page/2 , je me rend compte qu'il s'agit simplement de vérifier l'existance de méthodes.
Pour vous éviter à décrypter, je résume :
Si je fais :
template<typename T>
const T& min(const T& x, const T& y) {
return x < y? x : y;
}
et le concept associé :
concept LessThanComparable<typename T> {
bool operator<(const T& x, const T& y);
}
je dois donc préciser au compilateur avec un concept que T doit avoir un opérateur '<'?
Le compilateur n'est pas capable de le faire tout seul à la compilation ? C'est étonnant !
En Lisaac, (compilation globale oblige), tout est vérifié par le compilateur : si le compilateur dit OK, alors il n'y aura pas de problèmes.
Bref, j'ai parfois du mal à comprendre ce que ces features apportent de plus ?
En tout cas ça m'intéresse si ça peut nous permettre de l'implémenter, en mieux ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Déçu
Posté par Étienne . Évalué à 8.
Le compilateur n'est pas capable de le faire tout seul à la compilation ? C'est étonnant !
Il est tout à fait capable de le fait tout seul, l'intérêt des concepts c'est de rendre les messages d'erreur plus explicites, notamment lorsque plusieurs types templates sont imbriqués.
Par exemple avec un code comme celui-ci :
class Key {};
int main()
{
std::map<Key, int> myMap;
myMap[Key()] = 5;
}
Actuellement le compilateur te sort :
error: no match for call to '(std::map<Key,int, std::less, std::allocator<std::pair<const Key, int> > >) (Key)'Alors qu'avec les concepts il pourrait sortir:
error: Type Key doesn't respect concept LessThanComparableÉtienne
[^] # Re: Déçu
Posté par loufoque . Évalué à 7.
Il y a généralement de meilleurs messages d'erreur, mais c'est facile quand on a pas de surcharge/spécialisation (nécessaire à la spécialisation des algorithmes et à la méta-programmation) et que la signature d'un symbole contient nécessairement les types les plus restrictifs qui permettent l'exécution de son corps.
En C++, la résolution de surcharge ne prend en compte que la déclaration, pas la définition. C'est parce que généralement la déclaration est trop permissive (mais ça ne tient qu'aux gens de changer ça) que l'on obtient des messages d'erreurs "illisibles" quand une erreur survient, plus tard, dans la définition.
Néanmoins, rien n'empêche de mettre l'intégralité du corps de la fonction dans la signature, d'une manière ou d'une autre, ce qui permettra de rendre le symbole visible uniquement si les types d'entrées satisfont l'intégralité des expressions.
Ce serait encore plus pratique si on avait des lambdas polymorphiques, mais je ne suis pas certain qu'elles arrivent dans C++0x.
Pour ce qui est des modules, c'est facile en OCaml quand on implémente la généricité simplement avec un seul code de fonction qui prend en fait un pointeur générique. Quand on a un langage efficace comme C++, où tout objet n'est pas soit un entier soit un pointeur garbage collecté, et que donc par conséquent on doit générer une version de chaque fonction non monomorphique pour chaque type qui l'utilise, faire un système de modules pose certains problèmes car il faudrait en fait faire une seconde passe de compilation à l'édition de liens, ce qui n'est pas vraiment le modèle traditionnel.
OCaml, ce n'est pas si terriblement efficace, et ce par conception. Pour écrire du code efficace, (et ça concerne en fait tous les langages garbage collectés), bien souvent le seul moyen c'est d'allouer un gros Bigarray et de le manipuler comme si c'était de la mémoire. On se retrouve alors encore plus bas niveau que du C.
[^] # Re: Déçu
Posté par reno . Évalué à 4.
http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html
OCaml est *très* bien placé..
Ceci dit personnellement OCaml ne m'intéresse pas à cause de son accent sur le coté fonctionnel qui me rebute, je suis plus intéressé par D ou Scala.
[^] # Re: Déçu
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Et pendant ce temps
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
La proposition à l'état actuelle
ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1775.pdf
[^] # Re: Et pendant ce temps
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1782.pdf
La page qui récapitule tout cela
http://ftp.nag.co.uk/sc22wg5
[^] # Re: Et pendant ce temps
Posté par CrEv (site web personnel) . Évalué à 1.
# Les concepts, c'est du sucre
Posté par loufoque . Évalué à 1.
La même chose se fait parfaitement avec SFINAE, encore plus maintenant que le flou sur les expressions dans la signature a été levé.
La seule chose, c'est que l'usage généralisé de SFINAE n'est pas démocratisé.
[^] # Re: Les concepts, c'est du sucre
Posté par Sébastien Wilmet . Évalué à 1.
Que voulez-vous dans votre café ? Un peu de sucre syntaxique svp.
[^] # Re: Les concepts, c'est du sucre
Posté par monsieurmoche . Évalué à 2.
SFINAE + boost::enable_if, c'est un peu la solution de rafistolage pour arriver à ses fins. On arrive pas à une lisibilité de code exemplaire, rien qu'avec les paramètres fantômes :
//overload for list nodes
template<class SyntaxNodeT>
SyntaxNodeT
convert_node
(
const tree_node_t& node,
typename boost::enable_if<syntax_nodes::utility::is_list_node>::type* = 0
)
{
return convert_list_node(node);
}
//overload for optional nodes
template<class SyntaxNodeT>
SyntaxNodeT
convert_node
(
const tree_node_t& node,
typename boost::enable_if<syntax_nodes::utility::is_optional_node>::type* = 0
)
{
return convert_optional_node(node);
}
//etc...
Je préfèrerais écrire ça :
//overload for list nodes
template<ListNode SyntaxNodeT>
SyntaxNodeT
convert_node(const tree_node_t& node)
{
return convert_list_node(node);
}
//overload for optional nodes
template<OptionalNode SyntaxNodeT>
SyntaxNodeT
convert_node(const tree_node_t& node)
{
return convert_optional_node(node);
}
//etc...
Et encore, je vous montre pas la tronche des type traits qu'on se serait bien épargné de taper.
[^] # Re: Les concepts, c'est du sucre
Posté par monsieurmoche . Évalué à 1.
/*
* Utility types
*/
typedef char yes_type;
struct no_type
{
char padding[8];
};
/*
* list_node type trait
*/
namespace list_node_check
{
template<class T>
static
yes_type
check_sig(typename T::item*);
template<class T>
static
no_type
check_sig(...);
}
template<class T>
struct is_list_node
{
static const bool value = sizeof(list_node_check::check_sig(0)) == sizeof(yes_type);
};
/*
* optional_node type trait
*/
template<class T>
struct is_optional_node
{
static const bool value = false;
};
template<class T>
struct is_optional_node<syntax_nodes::optional_node>
{
static const bool value = true;
};
Un exemple d'intuitivité.
Et encore, je suis sûr qu'on peut trouver des alternatives bien pires à ce qu'auraient proprement permis les concepts.
# Commentaire de Herb Sutter
Posté par Étienne . Évalué à 8.
Sous forme de questions/réponses, il explique :
- Que la suppression des concepts s'est fait sur des décisions techniques et pas politiques
- Que ça ne devrait pas prendre trop de temps de supprimer tout ce qui concerne les concepts du brouillon de la spec
- Que ce n'était pas le point le plus important de C++0x
- Que ça n'a qu'une incidence modérée sur l'expressivité du langage
- Que les templates du C++, même sans concepts, restent très en avance en terme de généricité par rapport à ce qui est fait dans d'autres langage (il prend comme comparaison Ada, Java et .Net), il en a d'ailleurs fait personnellement l'expérience lors du développement de STL.NET
# C++ concepts: le festival off
Posté par Sebastien . Évalué à 2.
http://cpp-next.com/archive/2009/08/what-happened-in-frankfu(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.