Reprise du message précédent :
Quel est l'inconvénient principal, qui fait que tu choisis de ne pas rentrer Boost dans beaucoup de tes projets ? Trop de fichiers à inclure ?

on te l'autorise pas forcément, et le système spécial de build de boost, ses changements d'API/ABI/blabla, sa disparité de versions d'une distrib à l'autre, font que tu l'intègres pas forcément.
Biensur si ça correspond à une fonctionnalité (graph, etc), ça se tient.
 
Le fait est que l'inclure systématiquement, ça t'élargit considérablement ta boîte à outils, mais ça peut être un peu lourd à mettre en place pour 2/3 trucs utilisés au final.

aprés ca dépend. Ici on s'en sort en utilisant bcp qui permet de n'extraire que les features nécessaires.

C'est un langage de programmation interprété multi-paradigme... Oui, je trouve la différence suffisamment importante.  
 
Masklinn> Très constructif ^^

 
Est-ce que tu peux etre plus explicite et dire de quoi tu parles precisement? Je ne vois pas le rapport entre les rvalue reference et un operator== (j'avoue ne pas avoir lu l'article mais je crois connaitre assez bien la chose et ce que j'ai lu de l'article ne m'a rien appris).

C'est une comparaison. Pour écrire une classe de base correcte et optimale, on va passer de 4 fonctions membres (constructeur, constructeur par copie, operator=, destructeur) à 6 ...

sans vouloir etre pessimiste, deja que pas grand monde connait les 4 premières ....

 
J'ai du mal a voir le rapport avec l'heritage.  La grosse majorite de mes classes de base n'ont pas de constructeur de copie ni d'operator= (heritage de NonCopyable, declares prives mais pas implementes,...), et continueront a ne pas en avoir.  Et une bonne partie de mes classes valeurs ne participent pas dans des relations d'heritage.  
 
Sur le fond, l'utilisation de rvalues reference est essentiellement une technique d'optimisation (il y a quelques autres cas genre operator<< sur les streams qui peuvent en beneficier pour la semantique, mais c'est rare de vouloir modifier des temporaires pour des raisons semantiquement valables) -- et comme toute technique d'optimisation a mettre en oeuvre apres avoir verifie qu'il y avait un probleme de perf et que c'est une solution.  Et a priori, une bonne partie de mes classes valeurs n'ont aucune raison d'en beneficier.

 
Si tout mes étudiants faisait la même chose      

Dans la plupart des cas, cependant, l'implémentation est toujours la même et pourrait être générée par un éditeur un peu intelligent, comme eclipse le fait pour les get/set Java.
En Emacslisp, ça doit pas être la mer à boire.

Je disais "de base" dans le sens "toute bête"

Au final tu me diras, si on utilise des smart pointers, le problème se pose bien moins.

cette discussion est HS, on recentre sur le C++.

La question posée étant "Peut on considérer ce langage comme en dessous des langagesactuelles/futurs, ou est ce que selon vous le C++ restera  un langagephare dans l'avenir ", je trouve que considérer un langage tel que Python n'est pas se détourner du sujet. Python tend de plus en plus à remplacer C++/Java dans l'enseignement, et a déjà largement dépassé ces deux langages dans la recherche scientifique.

ok et sinon un bon lien concernant les rvalue reference pour ceux qui souhaite un papier synthétique:  http://www.open-std.org/jtc1/sc22/ [...] n2027.html

Dans la mesure où tu es la personne l'ayant fait déraper, tout le monde se porterait mieux si tu arrêtais tout simplement de participer stpmerssi

ok, lol.

Au fins, je vois pas trop d'ailleurs l'usage des const&&

Perf et resolution de problemes de faiseurs de bibliotheques (perfect forwarding, surcharge atypique où on modifie un des arguments comme avec << pour les flux, necessite de semantique de deplacement comme auto_ptr qui n'aurait pas eu besoin d'autant d'iterations pour se stabiliser)

et le support pour la move semantic

ça aurait quasi mérité un opérateur

il restait pas grnad chose comme token de libre ? Tu aurais vu quoi ?
a<-b ?

Je sais pas, un truc avec une flèche en tout cas, parce que ça va faire lourd les  X x(std::move(x0)). Enfin, on verra bien à l'usage.

a <- b s'interprete comme a < (-b)

oiui oui certes, c'etaits une idée en l'air
mais j'aurait rien eu contre un  a >>> b ou autre tuc non ambigu

Mais ça ne va pas être transparent/automatique l'appel au constructeur de déplacement ?

On fera des macros

ou un peu plus C++ spirit,  surcharger un opérateur qui fait l'opération de déplacement ou fait l'appel au construteur de déplacement

lequel d'opérateur :E

|= ou &=

tu veut dire les opérateur 'ou logique et affectation' qui, pour des types valeurs peuvent DEJA avoir un sens

oui je sais bien c'est pas parfait, mais si les |= et &= doivent être utilisés pour leur rôle premier, tu surcharges pas et t'utilises les méthodes de la std prévues à cet effet

en tout cas plus ça va plus le C++ sera clairement un langage d'élite un peu comme les langages fonctionnels le sont. Quand on voit la somme des choses à connaître désormais pour correctement programmer dans ce langage, on peut raisonnablement parier que  le nombre d'utilisateurs ne devrait pas augmenter de manière vertigineuse...

il en faut des langages d'élites sinon on va s'ennuyer taz, Un Prog et moi

 
Ou que les gens continueront à programmer Java-Style / en utilisant un subset du langage

 
C'est certainement -- et de plus en plus -- un langage a deux niveaux.  Et ceux qui suivent la normalisation etant plutot des experts, ils ont tendance a mettre l'accent sur ce qui les interesse.  Ce qui ne veut pas dire qu'il n'y a rien qui rendra la vie plus facile au programmeur median, ce pour qui "template metaprogrammation" ne veut rien dire.
 
Tout d'abord, un certain nombre de techniques avancees sont la pour permettre de mieux cacher le fait qu'elles sont utilisees.  Les concepts vont rendre les messages d'erreur quand on utilise des templates plus comprehensibles.  Les rvalues references permettent de diminuer le cout des l'abstractions -- et donc rendre moins commun la necessite de ne pas utiliser des abstractions fournies par les specialistes pour des raisons de performance.  Elles permettent -- ainsi que les templates variadiques -- aussi de rendre certaines abstractions beaucoup plus transparentes au niveau syntaxique.
 
Il y a aussi un certain nombre de petites choses dont on parle moins.  Mais qui vont a mon avis avoir un effet plus grand sur la vie quotidienne du programmeur moyen.  Dans cette serie, ma favorite est certainement "auto", mais la possibilite d'avoir >> pour fermer deux templates ou la nouvelle syntaxe de for.
 
Il y a aussi des choses se situant a un niveau intermediaire.  Les lambda en font partie.  D'un certain point de vue c'est un machin de specialistes, c'est trop complique, mais c'est dans les features avancees celles qui a le plus de chance d'etre utilisee par le programmeur lambda.

J'ai loupé ça , cad ?
 

ou plutot par des lambda-programmeur  

 
C'est pour itérer sur une collection: http://en.wikipedia.org/wiki/C%2B% [...] d_for-loop, un peu à la manière de boost::foreach

 
Dans le meme genre le keyword decltype va être très sympa ...

auto et decltype ça va bien aider, surtout pour les templates. Par contre les move-semantics, en effet ça risque pas mal d'alourdir le langage pour pas grand chose.
 
Au passage, petites question qui me tulupine pour Taz et Joel :
si je fais ça :
 

 
Le 3e appel n'est-il pas un bon remplacement pour la move-sémantic ?
On ne peut pas obtenir de ref d'une rvalue... sauf si on lui demande par une methode du genre Reference(), donc finalement je ne comprends pas trop pourquoi dès le départ les rvalues ne pouvaient pas être récupére en ref non-const.