Developpez.com

Club des développeurs et IT pro
Plus de 4 millions de visiteurs uniques par mois

C++0x : le draft final est disponible au téléchargement
Apportez vos commentaires à la norme

Le , par Jean-Marc.Bourguet, Expert éminent
Ici: http://www.open-std.org/JTC1/SC22/WG...2010/n3092.pdf

La suite des opérations: jusque début juillet pour faire parvenir les commentaires officiels.

3 réunions pour agir sur ces commentaires (août 2010, novembre 2010, mars 2011). La dernière peut décider soit de repartir pour un FCD (et donc des commentaires dont il faut tenir compte) soit pour un FDIS (ou il faut dire oui ou non).


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Alp Alp - Expert éminent sénior http://www.developpez.com
le 10/09/2010 à 13:04
Citation Envoyé par JolyLoic  Voir le message
De mémoire, ce n'était pas tant le PP qui prenait du temps, mais le fait que le jeu de fonctions candidates à la surcharge explosait. Mais je n'ai ni références ni chiffres en tête.

C'est ça.

Et effectivement, les templates variadiques permettent de gagner un peu de temps. Le compilo *sait* qu'on fait du variadique, on est plus obligé de générer (parfois inductivement en plus!) les n versions. Le compilo détecte le nombre de paramètres, instancie l'entité qui va bien dans son graphe sémantique, et c'est réglé.

C'est le genre de choses qui va pas mal aider sur les projets qui utilisent boost (ne serait-ce que boost.variant par exemple!).
Avatar de Goten Goten - Membre chevronné http://www.developpez.com
le 10/09/2010 à 13:23
J'attends les chiffres perso, je suis pas convaincu. Joel si tu passes par là, t'étais pas là quand on en a discuté ?
Avatar de ponce ponce - Membre averti http://www.developpez.com
le 13/09/2010 à 11:25
http://www.drdobbs.com/blog/archives...ilation_s.html

The 7 phases of translation [1]. Although some of these can be combined, there are still at least 3 passes over the source text. At least I never was able to figure out how to reduce it below 3. A fast language design would have just one. C++0x exacerbates this by requiring that trigraph and \ line splicing be unwindable to support raw string literals [2].

Avatar de guillaume07 guillaume07 - Débutant http://www.developpez.com
le 14/09/2010 à 8:02
mais au faite pourquoi la nouvelle norme n'est pas encore officiellement sortie, alors que le "final draft" a été voté, c'est quoi la différence ?
Avatar de gl gl - Rédacteur http://www.developpez.com
le 14/09/2010 à 8:50
Citation Envoyé par guillaume07  Voir le message
mais au faite pourquoi la nouvelle norme n'est pas encore officiellement sortie, alors que le "final draft" a été voté, c'est quoi la différence ?

Jean Marc l'explique dans le premier message de ce sujet :

Citation Envoyé par Jean-Marc.Bourguet  Voir le message
La suite des opérations: jusque début juillet pour faire parvenir les commentaires officiels.

3 réunions pour agir sur ces commentaires (août 2010, novembre 2010, mars 2011). La dernière peut décider soit de repartir pour un FCD (et donc des commentaires dont il faut tenir compte) soit pour un FDIS (ou il faut dire oui ou non).

Avatar de Klaim Klaim - Membre expert http://www.developpez.com
le 27/10/2010 à 22:33
Ca bouge a mort en ce moment coté C++0x, plein de problemes à régler! (via le blog d'herb sutter)

C'est la première fois que je suis ce genre de spécifications de près, alors j'ai l'impression que globalement ça se passe mal.

Ais-je tord? Ou je suis juste pessimiste?
Avatar de Goten Goten - Membre chevronné http://www.developpez.com
le 28/10/2010 à 0:10
C'est le blog d'Anthony williams (MR thread ) et non moi je vois rien d'alarmant..
Avatar de Klaim Klaim - Membre expert http://www.developpez.com
le 28/10/2010 à 10:38
Oui, je voulais dire que je suis tombé dessus en passant là : http://herbsutter.com/2010/10/22/c0x...nt-hot-issues/
Avatar de JolyLoic JolyLoic - Rédacteur/Modérateur http://www.developpez.com
le 28/10/2010 à 13:05
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.
Avatar de 3DArchi 3DArchi - Rédacteur http://www.developpez.com
le 28/10/2010 à 13:50
Salut,
Citation Envoyé par JolyLoic  Voir le message
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 ?
Citation Envoyé par JolyLoic  Voir le message
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)
Avatar de Klaim Klaim - Membre expert http://www.developpez.com
le 28/10/2010 à 14:11
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
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.
Offres d'emploi IT
Ingénieur développement c++/.net (c#) h/f
Sogeti High Tech - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)
Reconversion, futur ingénieur java jee h/f
Adaming - Ile de France - Paris (75000)
Chargé(e) d'etudes/essais spécialisation mathématiques-informatique algorythmie H/F
DCNS - Ile de France - Paris/Corporate

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C++