Nouvelles fonctionnalités du C++11 [Article]

[gbdivers]

Version en ligne de l'article, en cours de rédaction : Nouvelles fonctionnalités du C++11.

Suite à la sortie de la version 4.7 de gcc la semaine dernière, voici la liste des nouvelles fonctionnalités du C++11 prise en charge par gcc, avec des exemples de code explicatif. Je publierai progressivement les fonctionnalités prises en charge dans les versions précédentes de gcc.

GCC 4.7 [lien]

• Options de compilation
• Initialisation des données membres non-statique
• Alias de templates
• Constructeurs délégués
• Littérales définies par l'utilisateur
• Déclarations étendues de l'amitié
• Surcharges explicites de la virtualité
• Atomic operations

GCC 4.6 [lien]

• Options de compilation
• La constante nullptr
• Déclaration anticipée pour les énumérations
• Les expressions constantes généralisées
• Les unions sans restrictions
• Range-based for
• Règles sur la génération automatique pour le déplacement et la copie
• Autoriser les constructeurs par déplacement à lancer une exception

GCC 4.5 [lien]

• Les fonctions lambdas
• Les opérateurs de conversion explicites
• Les chaînes littérales brutes et unicode
• Les caractères universels dans les littérales
• Les types POD revisités
• Les types locaux et non nommés comme arguments template

GCC 4.4 (en cours) [lien]

• Paramètres template étendus pour les templates variadic
• Initializer-list
• Les variables typées automatiquement (à faire)
• Le SFINAE pour les expressions (à faire)
• Les énumérations à typage fort (à faire)
• Les nouveaux types de caractères
• Les fonctions par défaut et supprimées
• Sizeof étendu
• Les espaces de noms inline
• Les opérations atomiques
• La propagation des exceptions

GCC 4.3 (prochainement)

• Les références de rvalue
• Les templates variadic
• Assertions statique
• Déclaration du type d'une expression
• Right angle brackets
• Les arguments template par défaut dans les fonctions template
• L'identificateur prédéfini __func__
• Le préprocesseur C99
• Le type long long

Quelles sont les nouvelles fonctionnalités qui vous paraisse le plus intéressante ?
Allez-vous utiliser (ou utilisez-vous déjà) la nouvelle version de gcc 4.7 ? Quelles fonctionnalités utilisez vous déjà ?

Sources :

• Documentation de gcc 4.7 http://gcc.gnu.org/projects/cxx0x.html
• FAQ C++11 sur le site de Bjarne Stroustrup http://www2.research.att.com/~bs/C++0xFAQ.html
• Overview of the new C++0x de Scott Meyers (2010)
• C++0xCompilerSupport : liste à jour de nombreux compilateurs et leur prise en charge du C++11.

Remarque : le code est directement issu de la documentation de gcc, utilisable selon les termes de la licence consultable à la fin de cette page, ainsi que des drafts du comité de normalisation dont les liens sont donnés.

[Klaim]

Il me semble que les paramettres sont aussi optionels pour les lambda, mais c'est à confirmer avec le standard...

[gbdivers]

Envoyé par Klaim

Il me semble que les paramettres sont aussi optionels pour les lambda, mais c'est à confirmer avec le standard...

En effet, j'ai ajouté
Merci

[minnesota]

Salut,

Excellent!!!

Je me suis connecté juste pour plussoyer tous tes messages exemples, y compris celui de Klaim.

Reste plus qu'à trouver un bon package mingw/gcc 4.7.

EDIT:

Si vous en connaissez un bon au passage...

[gbdivers]

Envoyé par minnesota

Salut,

Excellent!!!

Je me suis connecté juste pour plussoyer tous tes messages exemples, y compris celui de Klaim.

Reste plus qu'à trouver un bon package mingw/gcc 4.7.

EDIT:

Si vous en connaissez un bon au passage...

Bonjour

Vous pouvez tester ces versions de gcc (4.6.3, 4.7.0 et 4.8) compilées pour windows : http://www.equation.com/servlet/equation.cmd?fa=fortran

[minnesota]

Merci pour la réponse.

Sinon, y'a ça aussi, avec différentes compilations personnelles de sezero, ray_linn, et rubenvb.
Est-ce que quelqu'un a déjà essayé, y'a des différences entre elles et celle de equation.com.
Merci.

Quoi qu'il en soit, je viens de télécharger celle de équation.com. Encore merci.

[minnesota]

Rebonjour tout le monde,

Bon ben j'ai rapidement utilisé quelques packages, mais aucun de ce que j'ai testé n'est homogénéifié, je ne sais pas si on peut dire ça comme ça. Aussi, de ceux que j'ai testé (* voir plus bas), seule la version de TDM-GCC (tdm-gcc-4.6.1) (http://tdm-gcc.tdragon.net/download) est autodétectée par l'edi codeblocks 10.05 (http://www.codeblocks.org/downloads), mais ça c'est très secondaire. Non, le gros inconvénient, c'est que hormis TDM-GCC, tous les packages W64 utilisent la version 3.14 de l'api windows (ming w32api) qui date de fin 2009, alors que la plus récente est la 3.17 de mars 2011 (http://sourceforge.net/projects/ming...W/Base/w32api/), par contre pour la version de gcc; tdm reste sur la 4.6.1 là où les autres sont à la 4.7

Voici la liste des versions utilisées (survolées) :

• gcc-4.7.0-32 de http://www.equation.com/servlet/equation.cmd?fa=fortran
• la construction perso de rubenvb, i686-w64-mingw32-gcc-4.7.0-3_rubenvb sur http://sourceforge.net/projects/ming...uilds/rubenvb/
• tdm-gcc-4.6.1 de http://tdm-gcc.tdragon.net/download

J'ai pas encore approfondi la question, mais j'ai déjà l'impression qu'il faudra se taper une installation manuelle des différents "modules" pour avoir quelque chose de récent et homogène.

[Klaim]

Et avec clang?

[minnesota]

C'est une mini phrase qui tombe comme une soupe sur un cheveu car je ne sais pas à quel message elle se rattache. Mais je ne connais pas clang.
Et à priori je ne pense pas m'y aventurer.

[Klaim]

Je ne comprends pas pourquoi, il est beaucoup plus simple a avoir sous windows que gcc, fournis a peu pret les memes features, en plus rapide, de meilleurs rapports d erreur et plus lisible si tu veux le modifier.

[minnesota]

Y'a une api windows fourni avec ? Si oui, est-elle plus riche que celle de mingw ?
Merci.

[Klaim]

Envoyé par minnesota

Y'a une api windows fourni avec ? Si oui, est-elle plus riche que celle de mingw ?
Merci.

Je ne comprends pas la question... c est juste un compilateur, ligne de cimmande, avec la meme interface que gcc (pour l instant).

[minnesota]

Je demandais ça parce qu’avec gcc mingw tu peux avoir un environnement de développement Windows presque complet en un seul package, et pas seulement le compilateur. Je verrais à l'occasion pour clang, une fois mon trio codeblocks, gcc, wxwidgets stabilisé. Aussi j'ai l'impression que codeblocks 10 débloque un peu par rapport à la version 8, le rafraichissement de la fenêtre n'est pas toujours complet.

[dragonjoker59]

Euh, à propos des littérales définies par l'utilisateur, apparemment il faut pour l'instant préfixer le nom de la littérale par '_'
De plus il faut que le type des paramètres et le type de retour soient des types littéraux (donc pas de std::string en paramètre ni en retour).
J'ai testé sur gcc 4.7 (compilé sur mingw) et clang 3.1

[gbdivers]

Envoyé par dragonjoker59

Euh, à propos des littérales définies par l'utilisateur, apparemment il faut pour l'instant préfixer le nom de la littérale par '_'

En effet, cela génère un warning

gcc-4-7.h:52: avertissement : literal operator suffixes not preceded by '_' are reserved for future standardization [enabled by default]

Envoyé par dragonjoker59

De plus il faut que le type des paramètres et le type de retour soient des types littéraux (donc pas de std::string en paramètre ni en retour).

Pour string comme paramètre, cela génère effectivement une erreur :

Code :

A operator"" _t(const string& str) { return A(str); }

gcc-4-7.h:66: erreur : 'std::string operator"" _t(const string&)' has invalid argument list

Par contre, utiliser string comme paramètre de retour fonctionne :

Code :

string operator"" _t(const char* str) { return string(str); }

C'est de ça dont tu parles ou j'ai mal compris ?

Merci pour les remarques, je complète et corrige le texte.
Dans le version finale, je fournirai un projet complet compilable montrant une utilisation de ces fonctionnalités

[dragonjoker59]

Méa Culpa, ce n'est effectivement qu'un warning pour le '_', par contre sous clang ça génère une erreur à l'utilisation.
Et pour les paramètres, il faut que ce soit des littéraux (donc effectivement pas de std::string, double, float et consorts)
Pour les retours, si ce n'est pas un littéral, il ne faut pas mettre l'opérateur en constexpr

[Luc Hermitte]

[J'ai lu en diagonale, désolé]
Je pense qu'il est important de garder la distinction entre initializer-list et initialization-list.
"Liste d'initialisation" est donc je pense une mauvaise traduction pour le N2672.

Je n'ai pas forcément mieux cependant que des barbarismes à proposer:
a- "liste initialisatrice"
b- "liste d'initialisants"
c- "liste d'initialiseurs"
d- "liste d'initialisateurs"

[gbdivers]

Envoyé par Luc Hermitte

[J'ai lu en diagonale, désolé]
Je pense qu'il est important de garder la distinction entre initializer-list et initialization-list.
"Liste d'initialisation" est donc je pense une mauvaise traduction pour le N2672.

Je n'ai pas forcément mieux cependant que des barbarismes à proposer:
a- "liste initialisatrice"
b- "liste d'initialisants"
c- "liste d'initialiseurs"
d- "liste d'initialisateurs"

J'ai hésité à traduire. Je l'ai fait pour 2 raisons :
* le but est bien d'uniformiser l'initialisation
* j'ai pas l'impression qu'utiliser le même terme peut troubler les devs

[Luc Hermitte]

Ce sont deux mécanismes encore plus distincts que "paramètre formel" et "paramètre réel" (aka "argument").

Ici, dans un cas il y a le mécanisme (rétrospectivement pas si bien nommé) qui permet de construire des attributs avant d'entrer dans le corps du constructeur, et dans l'autre cas la liste de paramètres réels qui pourra matcher directement les attributs (ou autres agrégats en transit) sans avoir à écrire de constructeur.

Je suis d'avis d'utiliser le terme précis qui servira à traduire officiellement initializer-list. Je soupçonne qu'il n’apparaisse pas avant la traduction d'une prochaine mouture du TC++11PL. Je ne sais pas si Loic et Michel ont déjà leur petite idée sur le sujet ou non.
En attendant je pense préférable d'éviter les pertes de précision en utilisant un terme unique qui n'aidera pas aux recherches dans textes et moteurs.

Voilà. Cela me perturbe autant que de vouloir mélanger surcharge et redéfinition. C'est une chose que beaucoup font quand ils parlent, et pourtant on tire, sur dvpz, vers le haut en ne procédant pas à l'amalgame.

[gbdivers]

En effet, j'ai craqué. Je pensais à l'initialisation des tableaux de style C (array initializer), qui a une syntaxe proche, pas du tout aux listes d'initialisation des constructeur. Je n'avais pas traduit le terme et en copie sur le forum aujourd'hui, j'ai pensé à un oubli de ma part J'aurais mieux fait de m'abstenir. Ca explique pourquoi j'avais pas compris ta remarque et pourquoi faire la distinction.

et dans l'autre cas la liste de paramètres réels qui pourra matcher directement les attributs (ou autres agrégats en transit) sans avoir à écrire de constructeur.

Tu parles de ça ?

Code :

1
2
3
4
class A {
   int a, b, c;
}; 
A x { 1, 2, 3 }; // initialisation sans constructeur A(int, int, int)

C'est un troisième mécanisme, non ? Ca correspond pas a priori au initializer-list (j'ai oublié le nom). Dans cette écriture, il n'y a pas de constructeur, les variables membres sont initialisées directement. Dans l'initializer-list, il y a constructeur spécifiquement définit pour récupérer le type std::initializer_list.

Donc par exemple

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class A {
    int a;
};
A x { 1 }; // ok, initialisation de membre, sans constructeur
 
class A {
    int* a;
};
A x { 1, 2, 3, 4 }; // erreur, on essaies d'attribuer 1 à m et 2, 3 et 4 ne correspondent pas à des membres
 
class A {
    vector<int> a;
};
A x { 1, 2, 3, 4 }; // erreur, idem, 1 est entré dans vector, 2, 3 et 4 ne correspondent à rien
A y {{ 1, 2, 3, 4}}; // ok, les premiers {} correspondent à l'initialisation des membres, le premier paramètre est {1, 2, 3, 4} et est utilisé pour initialisé vector
 
 
class A {
    A(std::initializer_list<int>) { ... }
    vector<int> a;
};
A x { 1, 2, 3, 4 }; // ok, constructeur initializer list

(j'ai pas testé ces codes, c'est le comportement que j'attendrais, par rapport à ce que j'en ai compris)

On a bien 4 choses différentes :
* les listes d'initialisation, pour initialiser les membres avant le corps du constructeur
* l'initialisation des tableaux style C (array initializer)
* les initializer list
* l'initialisation des variables membres sans passer par un constructeur
En effet, dans 2640, les 2 derniers concepts sont appelé initializer list, alors que dans N2672, on parle que du 3ème.
Il faudrait que je complète alors avec le contenu de 2640 (plus complet que 2672), j'avais pensé que le point 4 ne s'appelait pas initializer list et serait abordé dans un autre point de la doc de gcc