Discussion :

[Klaim]

Oui, je voulais dire que je suis tombé dessus en passant là : http://herbsutter.com/2010/10/22/c0x...nt-hot-issues/

[JolyLoic]

J'avoue quand même être un peu inquiet. Le problème, à mon sens, c'est la move semantic (To move or not to move et Exceptions and Destructors sont tous deux liés à ce sujet). Or la move semantic était sensée être "finie" depuis pas mal de temps. Les compilateurs l'implémentent tous.

Et finalement, on se rend compte seulement depuis peu qu'elle est inutilisable sauf par des experts prêts à écrire beaucoup de code, et toutes les tentatives pour essayer de corriger ça rencontrent des problèmes. Je ne sais que penser.

J'ai un peu l'impression que pas mal d'avancées orientée débutant (concepts, modules, bibliothèques filesystem, date_time...) ont été bloquées (pas assez mis en pratique dans les compilateurs, arrivant trop tard) alors que les avancées orientée expert (variadic template, move semantic) ont été fortement poussés en avant ("ça marche déjà", sauf que pour la move semantic, ça ne marche pas...).

Je pense que le plus grand risque aujourd'hui pour le C++ n'est pas technique, mais lié à un étiolement de sa communauté de développeurs. Et je ne suis pas certain qu'on le fasse évoluer dans le bon sens pour ça.

[3DArchi]

Salut,

Et finalement, on se rend compte seulement depuis peu qu'elle est inutilisable sauf par des experts prêts à écrire beaucoup de code, et toutes les tentatives pour essayer de corriger ça rencontrent des problèmes. Je ne sais que penser.

En quelques mots, c'est possible de poser les différentes problématiques ?

J'ai un peu l'impression que pas mal d'avancées orientée débutant (concepts, modules, bibliothèques filesystem, date_time...) ont été bloquées (pas assez mis en pratique dans les compilateurs, arrivant trop tard) alors que les avancées orientée expert (variadic template, move semantic) ont été fortement poussés en avant ("ça marche déjà", sauf que pour la move semantic, ça ne marche pas...).

Pas toute les évolutions simples n'ont été bloquées. Les lambdas sont une évolution déjà disponible qui ne nécessite pas une grande expertise et simplifie beaucoup de code. Dans la ligné des choses simples : les classes d'énumération et en particulier leur type sous-jacent voilà un truc que j'aimerais avoir rapidement, =default/=delete très pratique, les délégations de constructeurs, les listes d'initialisations, les héritages de constructeur, les initialisation à la déclaration des membres non statiques. Plus toutes les nouveautés de la STL (principalement l'intégration de TR1 qui n'était pas dispo avec Visual Express)

[Klaim]

En quelques mots, c'est possible de poser les différentes problématiques ?

En gros, pour résoudre je ne sais plus quel problème, il a été décidé que des move-constructor/operator seraient générés automatiquement pour n'importe quelle struct/type.

Seulement dans certains cas, l'application automatique de move operator rends les invariants faux. En gros si t'as

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class A
{
public:
    A() : m_values( 42 ){}
private:
std::vector<int> m_values;
};

Normalement en C++03 toutes les instances de A vont avoir 42 values, ça ne changera jamais meme si tu les copies.

Dans C++0x, l'operator move va faire que ton vecteur va se retrouver vide a la moindre copie ou manipulation impliquant une copie où un move serait plus implicitement pertinent.

Autrement dit, tu rendrais ton object bidon.

Ya plus de détails dans les deux documents listés dans les liens que j'ia posté.

La première solution serait de virer l'implémentation automatique des move constructor/operator OU une restriction sur les cas où ils sont générés (différent des cas ou les constructeurs/operateurs de copie sont générés).

Ou alors virer les rvalue reference mais ça serait alors une vrai catastrophe.