Reprise du message précédent :
Ben je pense qu'ils ont une idée de la façon dont les features sont implémentables, sinon on peut parfaitement définir des features qui sont impossibles à implémenter.
 
A mon avis, les compilos n'iront pas plus vite, ne serait-ce que parce que la syntaxe ne sera pas franchement simplifiée par rapport à la syntaxe actuelle.

la synatxe c'est peanuts. Ce qui coute c'ets les niveau de name lookup recursif.
Par exemple , sous Visual, int* et add_pointer<int>::type sont stockées comme 2 types différents et reliés via une table multi-entrées. DOnc un is_same<int*,add_pointer<int>::type>::type mets plus de temps à se resoudre que sous gcc. La syntaxe c'est trashé en qqs millisecondes alros que la resolutino de nom c'ets super chiant.

 
A mon avis une augmentation (sauf peut-être dans les cas où on utilise des moyens coûteux pour contourner l'absence d'une possibilité).
 

 
Ben oui.  Et le fait qu'une des deux propositions sur les concepts avait un prototype a joué un rôle majeur dans le fait que ce soit la proposition qui ait été choisie; et des choses difficiles/coûteuses en calcul dans ce prototype ont été refusées pour cette raison, même si des approches alternatives sans ces inconvénients existaient.  Et ce n'est pas la seule chose pour laquelle des prototypes ont joué un rôle.

Ca dépend. T'as des cas extrêmes comme les variadic ou tu peux remplacer des bidouilles template exponentielles (genre 2**N déclarations pour N paramètres) par un truc linéaire.
 
Mais bon suffit de comparer le temps de compilation d'un projet avant et après boost.format et là tu pleures. Sur un projet j'ai même était jusqu'à wrapper boost.format (truc bidon pour pas avoir à include boost, construire le formateur inline + 4/5 définitions operatorX(my_wrapper, my_type)) tellement ça bouffer en compilation et en volume de code objet.
(Dire qu'on me vendait ça me disant même "ouah la déduction de type statique ça permet de savoir à la compilation quel opérateur utiliser et donc d'avoir des IO plus performantes" ).

Ca me rappelle que quand j'ai voulu compiler FreeFEM++, j'ai cru un moment que g++ avait planté ou était parti en boucle infini: il y a un fichier qui prenait une demi-heure à compiler sur mon ancien PC.

 
Intuitivement, j'ai envie de dire que ca dépendra du projet. Quand je vois -à mon boulot- comme les temps de compilations sont intimement liées à la vitesse du disque et quand je pense à l'utilisation régulières de templates issus de la stl qu'on fait, j'ai bon espoir de voir le temps de compilation diminuer grâce aux templates extern ...  

Ah ce bon vieux g++, quand t'arrives à toucher le giga de mémoire, tu deviens un homme

La j'ai envie de dire: rajoute de la RAM, fais du g++ -pipe et ça touchera plus ton disque.
Et avec du pch (prise de tête mais bon), ça gagne quand même pas mal; Dernièrement ça me faisait un beau PCH de 70Mo, c'est quand meme pas rien.

le prochain visual supportera en partie le 0x si je me trompe pas, donc on va peut être dans la situation, où on aura des compilo le supportant partiellement et une norme toujours pas sortie :s

mais en dehors de l'implémentation, la syntaxe du langage est quand même attrayante

Clairement, j'attends avec imaptience un truc vraiment stable.

ça donnera rien ce langage

comme ta vie  

ok le GEEK retourne dans ta grotte

 
merci pour l'indication du -pipe, je ne connaissais pas. J'ai regardé brièvement, mais je ne vois pas d'option équivalente sous Visual Studio, mais ca nous servira probablement pour les plateformes où on a gcc
 
Edit : En fait, non, c'est inapplicable dans mon cas ... donc j'attends toujours cette petite évolution avec imaptience ...

ça sert à quoi boost.bind???

à construire une lambda expression à partir d'une fonction

mais les lambda expression, ça n'est justement pas utiliser en lieu et place des fonctions ? du moins c'est ce que je pensais, et si oui quel peut être l'intérêt de construire une lambda expression à partir d'une fonction ?

 
En gros :
 

 
cree un objet fonction qui contient tout ce qui faut pour appeler cos plus tard.

ok j'y vois un peu plus clair thx
 
 
 
/!\ _ EDIt _  Mais concrètement dans quel contexte ça s'utilise, à quel moment c'est indispensable ou fort utile ? _ EDIt _ /!\

dans ce lien il est fait mention d'une histoire de changed arity

 
ça correspond à quoi au juste, enfin une fonction ça à un nombre fixe d'argument (bon ok à part le va_arg du C) donc ça me laisse bien perplexe....
ça permets d'utiliser un seul function object pour pointer sur toute une famille de fonction ? c'est à dire un ensemble de fonction ayant le même nom mais un nombre d'arguement différent ?

deja fait un topic à part.
 
La changement d'arité correspondt soit à une curryfication soit à une decurryfication.
 
Soit f(int a, int b) une fonction binaire.
bind( f, _1, 5 ) genere une fonction paresseuse g tel que :
g(x) = f(x,5);
 
goto un tutoriel sur la programmation fonctionelle

d'acc merci, je savais pas que le C++ pouvait supporter ce paradigme de programmation

c'est pas vraiment le C++, c'est la lib boost/bind.
En STL c'est limité à passer d'arité 2 à 1 (std::bind2nd, std::bind1st).
 
Pour ce qui est de la norme et du compilateur, de nombreux ajouts de C99 étaient déjà supportés par les compilos avant 99, surtout sur GCC. Ca dépend surtout de la complexité de cet ajout et de son utilisation. Une fonction standard à ajouter, c'est simple, les templates variadics ou les concepts, c'est plus dur

pour clore le débat sur boost.bind (vu que c'est vrai que le topic est pas particulièrement dédiée à ça) cf un lien qu'explique un peu façon bind pour les nul mais qui à le mérite de poser les bases pour quelqu'un qui découvre bind :
http://www.developpez.net/forums/d [...] oost-bind/

developpez.netG  

oui je ss d'accord avec toi, moi non plus je suis pas fan de ce site, mais l'intérêt c'est qu'il présente beaucoup de sujet de manière très basique, et ça permets d'avoir une première approche de notions plus ou moins complexes, comme ça pour la suite de l'apprentissage d'une notion ou d'un concept on sait un peu plus où on va,car perso la doc de bind sur le site de boost m'a apportée beaucoup plus de questions que de réponses

le gars me fait un peu pitié à dire ouais y a ce qui faut dans  boost mais nonon je veut pas de dependances :€

D'ailleurs boost.function/bind sera intégré tel quel dans 0x ?

ca habitera dans std::tr1 mais de tete oui. En general, les lib boost de "future compatibility" suivent au mieux l'interface préconisée par le standard

j'ai du mal à voir la place de std::move() dans les nouvelles features de move semantic et de perfect forwarding, ça servira à quoi ?

Non, le changement d'arité (en tout cas avec les exemples de bind postés ici) correspond à de l'application partielle. L'application partielle est triviale à faire avec des fonctions currifiées (ou schönfinkelisées, certains préfèrent), mais c'est pas la même chose

merci je m'embrouille tout le temps

Quelqu'un à des infos sur ce qui sera inclue dans le tr2 ?