"move semantic" testée avec gcc tdm 4.8.1

Bonjour,
Tout d'abord comme je ne sais pas comment c'est traduit dans les documentations en français les termes "move semantic, move constructor..."
donc je les laisse en anglais.
J'ai voulu savoir quand est ce que le "move constructor" est appelé?
J'ai utilisé l'exemple trouvé sur le site msdn
http://msdn.microsoft.com/fr-fr/library/dd293665.aspx
et le testé avec le compilateur tdm gcc 4.8.1, j'ai mis le résultat en pièce jointe
Il y a 2 points que je n'ai pas compris, si quelqu'un peut m'expliquer:
Pourquoi les constructeurs de copie sont appelees? Si c'est nécessaire d'appeler les construteurs de copie pourquoi l'appel de ce constructeur n'y est pas pour "length = 50"
Merci

Edit : J'ai barré ce qui est faux dans cette réponse, voir réponse de Flob90 plus bas.

Il serait intéressant de voir quand ils sont appelés, mais j'ai l'impression que c'est pendant la réallocation de la mémoire pour le vector et la recopie vers la nouvelle zone. Ce qui indiquerait que c'est un problème non pas du compilateur, mais de la bibliothèque standard utilisée qui ne ferait pas de move lors de cette réallocation. Il faudrait faire du debug pour confirmer (mettre un breakpoint dans le constructeur de copie, et afficher la call stack).
Ce expliquerait que pour 50 il n'y ait pas besoin, puisqu'il est mis en dernier.

Salut JolyLoic,
J'avais regarde la call stack mais j'avoue que j'ai du mal a voir, d'ou ce post
"Ce expliquerait que pour 50 il n'y ait pas besoin, puisqu'il est mis en dernier. "
S'il n'y a pas de "move constructor" le compilateur va appeler le constructeur de copie, et c'est ce qu'il a fait pour le dernier mais par contre il a appele le "move constructor" et "copy constructor" pour les 2 premiers,j'ai du mal a comprendre

Mets ton move-ctor en noexcept et ça devrait donner ce que tu veux.

Si tu as un copy-ctor (avec const&) et un move-ctor non noexcept, il est légitime que le vecteur privilégie l'utilisation du copy-ctor pour les déplacements internes pour conserver une résistance forte aux exceptions.

Ah, oui, c'est ça ! Et comme visual C++ ne gère pas encore correctement les noexcept, c'est "normal" qu'il n'ai pas ce comportement.