Reprise du message précédent :
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.

les rvalues c'est principalement pour gérer l'overload propre de truc comme :
 

 
En gros :
 

 
Dans ton cas, tu cree une dangling reference ce qui est une UB.

UB?

Lis le lien que j'ai posté, y a des cas pratiques comme le tiens.

 
J'ai l'impression que tu confonds reference de rvalue et semantique de deplacement.  Les premieres sont des "objets" du C++ (je mets entre guillemets parce que objet a un sens technique et que les references n'en sont pas), la deuxieme une propriete qu'on peut vouloir donner a des classes.  C'est deja plus ou moins possible de le faire (voir std::auto_ptr), mais au prix d'une complexite et de limitations.  Les premieres permettent de le faire plus facilement, et permettent d'autres choses.
 

 
Je ne vois pas l'UB tant que f1() ne conserve pas la reference au dela de son retour.  Le temporaire a pour duree de vie l'expression et donc ne peut pas etre detruit avant le retour de f1().

je pensais que t(42) etait détruit plus tôt que ça c'ets pour ça

La duree de vie des temporaires n'a a ma connaissance jamais ete plus courte.  Des vieux compilateurs -- et des plus recents tels que ceux de Sun dans des modes de compatibilite -- etendaient meme la duree de vie jusqu'a la fin du bloc.

Vous pourriez quand même lui répondre... UB = Undefined Behavior

intéressant ce bout de code concernant les temporary values en C++, dans le genre chercher l'erreur : D

mmmhhh interressant comme exemple, en plus je crois avoir du code avec cette syntaxe
J'avais pas fait attention, je pense que ça me vaudra un bon grep ça !
 

Je reconnais que oui... faudrais que je me trouve un exemple bien spécifique, parce que là je ne comprends toujours pas ce que ça apporte par rapport à une référence non-const.

je te rassure t'es pas le seul pour qui ça n'est pas clair

On ne peut pas binder une référence non const à un temporaire.  Le choix est tout à fait volontaire (et si j'ai bonne mémoire, on a changé la définition du C++ à un moment donné pour l'interdire) parce que dans la plupart des cas, ce n'est pas désirable: ceci est vraisemblablement une erreur:

Les rvalues références ont été introduites pour le permettre et pour permettre d'appeler de surcharger une fonction sur le fait qu'elle soit appelée avec un temporaire ou non.  
 
Voir http://www.open-std.org/jtc1/sc22/ [...] n2027.html et les documents cités.  Je crains qu'on ne puisse faire que paraphraser ces sources.

ben là ton exemple, je ne vois pas ce qu'il fait, il ne peut pas incrémenter la constante, donc 5 peut être converti en int&& ? même pas seulement en const int&&, mais carément en int&& ??
 
Je crois que je comprends encore moins avec cet exemple, et je pense encore + que ça n'apporte rien de plus qu'une reférence. Ma question reste : pourquoi introduire cette notion et tout ce qui va avec plutôt que d'accepter une reférence depuis une rvalue, comme le fait par exention visual++, et comme on peut le faire de façon portable avec une méthode Reference, comme dans mon exemple ?
 
edit, citation de ton lien :

La formation est polie, j'aurais mis "what the fucking fuck" mais l'auteur est consciens que c'est pas intuitif

 
Tu as voulu dire quoi par là ? tu aurrais un ptit exemple vite fait stp ?

je viens de lire ton lien, je comprends mieux, mais je reste scpetique sur l'intérêt par rapport à une référence non-const. Certes cet exemple l'illuste :
 

 
en gros la reference de type && sert à indiquer explicitement qu'on peut se permettre de déplacer le contenu de sa source, alors qu'avec la référence non-const, ça peut ne pas être le cas, donc on ne le fait pas.
 
Mais pourquoi ne pas s'appuyer sur std::swap alors ?
Bon c'est vrai swap il se force à échanger les contenus alors que operator=( T&& t ) se permet de "vider" t sans remplacer son contenu par celui de this.
Mais bon je sens que je me servirai de ces nouvelles référence comme une version portable de l'extension de visual c++ qui accepte une rvalue en ref non-const.
Et je maintiens, jusqu'à preuve du contraire, que :

ça compile pas... avec const int&& si, mais quel est l'intérêt du const&& ? ça a exactement la même sémentique que le const&.

 
 
ça fait comprendre un peu mieux (extrait de wiki)
 
In standard C++, temporaries (termed "R-values", as they lie on the right side of an assignment) can be passed to functions, but they can only be accepted as const & types. As such, it is impossible for a function to distinguish between an actual R-value and a regular object that is passed as const &. Furthermore, since the type is const &, it is not possible to actually change the object.
 
C++0x will add a new reference type called an R-value reference. It is defined as typename &&. These can be accepted as non-const values, which allows an object to modify them. This modification allows for certain objects to create move semantics.
 
For example, a std::vector is, internally, a wrapper around a C-style array with a size. If a vector temporary is created or returned from a function, it can only be stored by creating a new vector and having it copy all of the R-value's data into it. Then the temporary is destroyed, deleting its data.
 
With R-value references, a "move constructor" of std::vector that takes an R-value reference to a vector can simply copy the pointer to the internal C-style array out of the R-value into the new vector, then leave the R-value in an empty state. There is no array copying, and the destruction of the empty temporary does not destroy the memory. The function returning a vector temporary need only return a std::vector<>&&. If vector has no move constructor, then the copy constructor will be invoked with a const std::vector<> & as normal. If it does have a move constructor, then the move constructor can be invoked, and significant memory allocation can be avoided.
 

 
Orthogonalité et ça permet de faire la différence entre temporaire et
lvalue.  On peut surcharger f(T const&& ) et f(T cont& ).

la flemme d'ouvrir un new topic, pour une toute petite question...

cette écriture là int*& rpInt

est une référence sur un pointeur ou un pointeur sur une référence?

les qualificateurs de types se lisent de droite à gauche
 
int*& : reference sur pointeur
 
prendre l'adresse d'une reference n'a pas de sens donc un pointeur de reference non plus

parfait merci

toujours pas de date pour le C++0x ?

2009 ou jamais

0x est une valeur héxa (c'est un gag/excuse semi-officiel) donc on passera à 0A si ça ne se fait pas cette année.
Mais c'est vrai que ça traine un peu, ça me saoule de devoir encore me tapper des trucs standard dégeux en sachant très bien qu'après la sortie de la norme ça aurait pu être écrit proprement.
Heuresement qu'il y a boost, mais ça ne suffit pas.

 
Tu as lu le machin en essayant de tout comprendre et d'en verifier la coherence?  
 

 
Entre une norme cette annee avec des problemes de fonds et une norme l'annee prochaine; je sais ce que je prefere.  Si pour arriver a l'implementer, il faut non seulement la norme mais une liste de DR longue comme un jour sans pain, ca ne facilitera pas les choses.  Or ce n'est pas le lendemain de la publication de la norme que tu auras un compilateur standard sur toutes les plateformes cibles... (on n'en a deja pas tellement qui pretende implementer completement celle de 98; et la situation en C est encore pire).

Oh, pour le C l'implémentation a bien avancé quand même. Dix ans après, la plupart des compilos sont presque compatibles C99 non ?

OK mais les trucs à la con niveau librairie, c'est dommage d'attendre 10ans pour un shared_ptr correct ...

Sous Unix, ça va plus ou moins -- mais regarde la page de GCC consacrée au support de C99 et regarde les changements entre les versions.  Ca bouge a une vitesse de limace asmatique grimpant au sommet de l'Everest.  En fait, je ne suis pas sur que ça bouge encore.  Et à ce que j'ai compris, en embarqué et sous Windows, à part pour quelques broutilles (genre extensions qui par hasard étaient déjà présentes), c'est ignoré complètement -- la dernière fois que j'ai regardé les gens de MISRA ignorait complètement C99 et MS ne fournissait même pas des fonctions de la bibliothèque C99 qui n'ont besoin d'aucun support dans le compilateur alors qu'ils ne font que revendre la bibliothèque de Dinkumware qui a tout ce qu'il faut....

Tu as vu à quel point la bibliothèque est maintenant liée aux concepts -- shared_ptr l'est peu ou même pas -- et au multithread (et là tu as des implications même pour shared_ptr)?

Et qu'est-ce que tu fais pour accélérer les choses?

De quel "machin" tu parles ? J'ai juste dit que pour répondre à ceux qui demandaient si c++0x impliquait que la date soit <= 2009, le consortium avait dit, comme une boutade, que 0x était une valeur hexa, je ne voit pas le rapport avec une quelconque "coherence".

 
Du brouillon de C++0X.
 

 
Tu as aussi écrit:

ah c'est là dessus que t'as répondu, je pensais que c'est l'histoire de la date en hexa qui te genait.
Je suis d'accord avec toi sur la priorité laissée à la qualité plutôt qu'au respect des dates, mais je maintiens qu'ils sont à la bourre et que maintenant 11 ans, ça fait beaucoup dans l'histoire d'un langage.
Je me demande s'ils n'auraient pas du faire une norme intermédiare, genre en 2006, avec les trucs simples à implémenter, déjà prêt en extention par tous les compilos, et pratiques, genre le mot clé auto pour l'inférence (j'en ai marre des std::map< int, std::string >::const_iterator it = ... au lieu de auto it = ... même avec des typedef), les macros variadic, les templates de types locaux, decltype/typeof, les hash_map...

 
Considérant le processus de normalisation de l'ISO pour sortir quelque chose en 2006 il aurait fallu prendre la décision en 2002/2003 en ayant déjà une bonne idée de ce qui allait être ajouté.  Ce n'était pas le cas.  On finissait à l'époque de fixer les bugs les plus criant de la norme de 98 et on commençait tout juste à se demander ce qui pourrait être ajouté.

Depuis le temps que le comité C++ se prend le chou sur des problématiques insolubles, D a largement eu le temps d'évoluer et de résoudre N fois plus élégamment nombre de problèmes posés par C++.  
Y'a un moment, il faut savoir évoluer, non ?

D on en reparle quand le compilateur arrivera à compiler les exemples qui viennent avec lui et que phobos commencera à ressembler à une vrai bibliothèque utilisable.

Moi je les compile les exemples.
OK, il faut modifier le script fait pour DOS (3 secondes), et l'exemple client/server windows ne fonctionne pas, mais pour le reste, chez-moi-ça-marche.com. Mais ok, je reconnais que fournir le truc avec un script qui ne fonctionne que sous DOS est foireux à la base.
Quand à Phobos, les dernières versions pour D2.0 commencent à être assez décentes. A coté de la lib standard C++, en tout cas, surtout depuis l'ajout du module algorithms qui émule la STL.

j'ai pas dit que c'etait atroce masi le coup du script come on
Et mon dernier date un peu, masi ça m'avait tellement rebuté que je m'etais dit basta, j'ai aps de temps à perdre sur ce truc.

Phobos 2 a une belle tête effectivement. Moi perso, le jour ou c'est main-stream ou du moins stable je saute dedans à pieds joints. Mais, non merci

Euh ouais, tout ce qui est prédicat sous forme de string, ça me fait violemment peur, et je parle même des std.<mon_os_à_moi> et tous les machins "bug: only works on x86"

Je sais plus si j'avais posé la question ici, mais à votre avis avec l'ajout de toutes ces nouvelles features, on devrait plutôt voir une augmentation ou une réduction des temps de compilation ?
 
Naïvement les 2 raisonnements opposés que je vois c'est que d'un coté plus de feature signifie plus de boulot pour le compilateur, des features peut-être algorithmiquement lourdes à décider, etc... Et de l'autre coté, certaines features devraient faire sauter des pages entières de code "d'émulation" dans boost (je pense aux versions d'un template répétées pour 1 à 15 arguments par manque de variadic par exemple), réduire la profondeur des templates à évaluer, et même tout simplement la quantité de texte à parser à chaque fois.

la norme ne dit pas comment implanter tous ça. DOnc si les compilso sont bons ca ira plus vites, sinon non

 
Oui mais j'imagine que dans la conception de la norme ils réfléchissent un minimum à ce qu'ils mettent (une raison de plus au fait que ça prennent 3 plombes) et qu'ils ont une idée de la complexité des features (du point de vue algorithmique, pas en terme de compréhension, ça c'est une cause perdue de toute façon). Après peut-être qu'ils s'occupent uniquement du temps d'exécution...

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.