C1x : future version du langage C

C1x : future version du langage C
Le nouveau Release de GCC intègre déjà certaines de ses fonctionnalités


La nouvelle ne date pas d'hier, mais pour ceux qui ne sont pas encore au courant, une nouvelle version du C est en fait en cours d'élaboration et le dernier release de GCC (du 26 octobre 2011) intègre même déjà certaines de ses fonctionnalités.

Ce langage, couramment appelé C1x, est destiné à remplacer le C99, le standard actuel. Il est clair que le C99 a terriblement été un échec, notamment en raison du choix de Microsoft de ne pas le supporter. Mais ce n'est pas tout. Le C99 a peut-être aussi échoué parce qu'il n'apportait rien qui soit véritablement essentiel au langage.
Certes, les nouvelles fonctionnalités (types, commentaires, déclarations, initialisations, bibliothèque standard, etc.) étaient toutes aussi intéressantes les unes que les autres, mais aucune qui ouvre réellement de nouveaux horizons pour le langage.

Cette fois-ci, c'est différent. Parmi les nouveautés majeures, on peut citer : le contrôle des alignements en mémoire, un meilleur support d'Unicode, la normalisation des structures et unions anonymes, la normalisation des fonctions "secure" de Microsoft (et suppression définitive de la fonction gets au profit de gets_s) et le support du multithreading (<threads.h> et <stdatomic.h>). Comme d'habitude, des macros permettent de tester si telle fonctionnalité est disponible ou non dans une implémentation donnée. Par exemple, la macro __STDC_NO_THREADS__ permet de savoir si l'implémentation supporte ou non les threads.

:fleche: Le dernier draft de cette norme date du 12 avril 2011 et est disponible ici.

Source : change log de GCC

:fleche: Alors, qu'en pensez-vous ?
:fleche: Approuvez-vous ces changements ?
:fleche: En attendez-vous d'autres ?

Citation:

---

suppression définitive de la fonction gets au profit de gets_s

---

Bon c'est déja ça. Sinon scanf, quand est ce qu'il lui font la peau?

Pour ce qui est du mulithreading, il existe déja plein de librairie pour ça. Pthreads marche très bien et est plus ou moins standard, alors quel interêt de balancer encore un autre standard ça me fait penser à ça

Citation:

---

Envoyé par 6-MarViN

Bon c'est déja ça. Sinon scanf, quand est ce qu'il lui font la peau?

---

Ce n'est pas comparable. gets() introduit un buffer overflow potentiel qu'il n'est pas possible de pallier. Ça peut arriver avec scanf() aussi mais il y a quand même moyen de spécifier une taille de champ.

Ce qu'on reproche à scanf(), c'est d'être difficile à utiliser et de ne pas être ce qu'il y a de plus indiqué pour débuter, surtout s'il ne s'agit que de lire un nombre ou une ligne de texte. Ça s'explique cependant parce qu'elle est censée être la réciproque de printf(), et qu'elle s'utilise de la même façon.

Mais autant, je suis assez d'accord pour orienter d'emblée les nouveaux venus vers d'autres fonctions, autant ça me ferait suer qu'elle disparaisse complètement au quotidien.

Mouais,

C99 n'est pas encore entierement supporte par tous les compilateurs : http://en.wikipedia.org/wiki/C99#Implementations

C1x apporte aussi de nouvelles joyeusetes qui ne servent a rien:

• no-return function : le type void est visiblement trop complexe pour les pauvres demeures que nous sommes
• at_quick_exit et quick_exit : si on concoit bien son programme, pas besoin de ces cochonneries qui, sauf erreur de ma part, vont necessiter l'utilisation de variables globales la ou ce n'est pas necessaire.
• ...

Les no-return functions ne sont pas des fonctions void, mais des fonctions qui ne retournent pas (comme abort() ou exit()).

Pour at_quick_exit() et quick_exit(), le débat n'a pas lieu d'être puisque la fonctionnalité que tu critiques est déjà disponible en C99 et même C89 avec atexit() et exit(). at_quick_exit()/quick_exit() amènent simplement un deuxième jeu de fonctions qu'on peut utiliser quand il n'est pas pertinent d'utiliser les fonctions installées avec atexit() (et appelées en cas d'exit()).

Je me suis penche un peu plus sur les changements entre C99 et C1x, et j'avoue que le fait de rendre optionnel en C1x des choses (les VLA (tableaux a longueur variables) et les complexes) qui etaient obligatoires en C99 me laisse pantois.

En gros, j'ai un peu l'impression que la norme n'est plus une norme que chacun doit respecter, mais que c'est l'inverse : les gens n'ont pas voulu implementer les VLA, donc on les rend optionnels.

Certes, c'est un point tres complexe a integrer dans un compilateur, mais est-ce raisonnable de casser la backward compatibilite sur une norme ??

Citation:

---

Envoyé par 6-MarViN

alors quel interêt de balancer encore un autre standard

---

il ne sera plus un library à part entier.

Citation:

---

Envoyé par matafan

Les no-return functions ne sont pas des fonctions void, mais des fonctions qui ne retournent pas (comme abort() ou exit()).

---

Ah oui, vraiment ? Ce qui veut dire ? Imaginons qu'une fonction f1 appelle une fonction f2, qui est no-return. Que se passe-t-il à la fin de f2 ? Le flux d'exécution ne va pas exécuter l'instruction suivant l'appel de f2 dans f1 ? Mais alors que se passe-t-il ?

@traroth : Effectivement, le code suivant l'appel de f2 ne sera jamais exécuté, c'est déjà ce qui se passe lorsqu'on appelle exit() ou abort() :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

void f2() { exit(0); }   void f1() { f2(); /* le code suivant l'appel à f2 ne sera jamais exécuté */ }

---

noreturn permettra juste d'indiquer au compilateur qu'on ne sortira jamais d'une fonction (soit parce qu'on sort du programme, soit parce qu'on rentre dans une boucle infinie inconditionnelle). Le compilateur pourra donc optimiser le code (par exemple en omettant de poser l'adresse de retour sur la pile).

Citation:

---

Envoyé par Melem

la normalisation des structures et unions anonymes

---

Ça veut dire que :

Code:

---

1 2 3 4 5 6

typedef struct { int a; int b; } MaStruct;

---

n'est pas normalisé ??
ou alors il s'agit seulement de ça :

Code:

---

1 2 3 4 5 6

struct { int a; int b; } aStruct;

---

??

@atha2 : Je pense qu'il s'agit de pouvoir écrire

Code:

---

1 2 3 4 5 6 7 8 9

struct S { union { int i; float f; }; };

---

plutôt que :

Code:

---

1 2 3 4 5 6 7 8 9

struct S { union { int i; float f; } u; };

---

Et de pouvoir traiter les membres de l'union comme s'ils faisaient partie de la structure englobante (comme c'est le cas en C++).

atha2, une structure anonymes c'est ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

struct s1 { int a; int b; };   struct s2 { int c; int d; };   struct s12 { struct s1; /* On ne nomme pas le champ */ struct s2; /* On ne nomme pas le champ */ };

---

Et on peut accéder aux champs de la structure anonyme directement de cette façon :

Code:

---

1 2	struct s12 mys12 = { { 1, 2 }, { 3, 4 } }; printf("%d %d %d %d\n", mys12.a, mys12.b, mys12.c, mys12.d);

---

Certains compilateur les supportent déjà et c'est extrêmement pratique, par exemple pour faire "hériter" deux structures d'une structure commune et y accéder de manière transparente.

C'est aussi très pratique pour les unions, dont le nom ne sert généralement à rien (mystruct->u.myfield... Qui n'a jamais pesté en écrivant celà).

@matafan et Niark13 : merci :ccool:
Je pensai que le anonyme faisait référence au nom du type (comme les classes anonymes en Java par exemple) et pas au nom du champ.

Citation:

---

Envoyé par gangsoleil

Je me suis penche un peu plus sur les changements entre C99 et C1x, et j'avoue que le fait de rendre optionnel en C1x des choses (les VLA (tableaux a longueur variables) et les complexes) qui etaient obligatoires en C99 me laisse pantois.

En gros, j'ai un peu l'impression que la norme n'est plus une norme que chacun doit respecter, mais que c'est l'inverse : les gens n'ont pas voulu implementer les VLA, donc on les rend optionnels.

Certes, c'est un point tres complexe a integrer dans un compilateur, mais est-ce raisonnable de casser la backward compatibilite sur une norme ??

---

Une implémentation simple* est d'allouer dans le tas le tableau (de ce que j'ai vu, la norme ne précise pas où doit être alloué le tableau) et d'ajouter un free à la fin de la fonction / block. Franchement ça doit pas prendre plus de 10 minutes à implémenter.

*mais pas forcément efficace. Je n'ai jamais fait de benchmark pour comparer les 2 types d'allocation mais j'imagine qu'allouer sur le tas est moins efficace.

Citation:

---

Envoyé par 6-MarViN

Bon c'est déja ça. Sinon scanf, quand est ce qu'il lui font la peau?

---

Elle est très bien cette fonction, qu'as-tu a lui reprocher en dehors du fait qu'elle soit souvent apprise à des débutants qui n'ont pas la moindre idée de comment gérer une chaîne formatée ?
Là où gets() nous obligeait à faire confiance à la chaîne entrée, scanf() peut tout contrôler, de la simple longueur de chaîne jusqu'à un modèle strict imposé par des regex.
Ça fait économiser pas mal de lignes de test, d'après moi.

Moi je suis déçu qu'il y ai toujours pas une gestion des répertoire de manière standard. Pourquoi ne pas mettre dirent.h dans le standard du C ?

Je pense que c'est bien plus important que les threads qui eux ont été prévus dans C1x