Réunion des comités de normalisation de C et C++

Du 19 au 24 octobre, aura lieu à Hawaii une rencontre du comité de normalisation C++, ce qui est une étape importante vers la prochaine norme (C++17). Chose intéressante, cela se passe quasiment 30 ans, jour pour jour, après la mise sur le marché du premier compilateur C++ : CFront !

Cette rencontre du comité C++ (groupe ISO WG21) sera immédiatement suivie d'une rencontre du groupe WG14 qui travaille à l'évolution du langage C !

A cette occasion, Aurélien Régat-Barrel, développeur de la communauté francophone, va participer à ces deux meetings l'un après l'autre (en tant que simple spectateur). Son but est de réaliser des interviews (vidéo si possible) de ces personnes qui sont à l'origine de ces deux grands langages de programmation. Il souhaite les questionner tant au sujet des travaux en cours sur C et C++, que sur leur ressenti et vécu à propos de toutes ces années consacrées à faire évoluer nos habitudes de programmation.

C'est donc une occasion unique qu'il nous propose pour partager nos questions et interrogations avec ceux qui préparent le C et C++ de demain. Il s'efforcera alors, en fonction des possibilités, d'obtenir des commentaires et éclaircissements de la part des plus grands experts !

Et cerise sur la gâteau, il nous propose de suivre l'avancement de ses échanges en publiant un compte rendu journalier durant toute cette période. De cette manière, il nous sera possible de contribuer "en temps réel" à recueillir un maximum d'informations utiles. Et aussi, ne l'oublions pas, à faire remonter notre soutien et enthousiasme (ou pas!) à propos de certaines évolutions en cours !

A ce jour il a prévu de faire de mon mieux pour obtenir des détails sur :

• En C++ :
  • le processus de normalisation ISO : pourquoi faire ? Comment ça fonctionne ? Comment participer ?
  • les travaux en cours, tant au niveau de C++17, qu'au niveau des différents Study Groups, en particulier:
    • Concurrency and parallelism ;
    • Modules (remplacement des hearders!);
    • File System ;
    • Networking (ASIO) ;
    • Compile-time reflection ;
    • Concepts ;
    • STL Ranges ;
    • Database-related library interfaces ;
    • Undefined and Unspecified Behavior (simplification du langage) ;
    • Travaux sur un lib graphique 2D.
  • une ABI standardisée
  • la simplification du langage via la dépréciation de fonctionnalités
• En C :
  • Il n'a pas fait de C depuis longtemps, aussi a-t-il besoin de notre aide et des idées pour obtenir des échanges de qualité !

A noter un début de discussion sur le sujet sur dvpz où quelques idées ont déjà été émises.

Tout ça pour dire, n’hésitez pas à commenter ici nos propos tenus là bas si vous n'y avez pas de compte.

J'ai mis au moins 30 secondes pour trouver lesdits forums, donc je pose ça ici :

• http://www.developpez.net/forums/d1546673/c-cpp/cpp/normalisation/rencontre-comite-cpp-posez-vos-questions/
• http://www.developpez.net/forums/d1546698/c-cpp/c/rencontre-comite-normalisation-c-posez-vos-questions/

Intéressant ! C'est possible de demander au comité de standardisation du C s'ils ont l'intention d'intégrer les espaces de noms comme en C++ ? C'est à mes yeux le seul concept qui améliorerait le langage sans le dénaturer. Quant à Ranges, ça n'avait pas été introduit en C++14, est-ce que le comité pense que cela sera bon pour C++17 ?

Bah c'est un TS, donc ça dépendra plus de est-ce que le boulot sera fait quand ils valideront la prochaine norme. Il y a une vidéo de la CppCon dessus, il donne peut-être plus de détails

Oui. Il y a une video d'Eric Niebler (enregistrée lors des CppCon2015) où il présente ce qu'il a fait et ce qu'il lui reste à faire.

Salut,

Pour ma part, j'aurais plusieurs suggestions spécifiques sur le C :

• Inclure des opérateurs pour gérer les rotations de bits.
• Inclure un moyen pour détecter/éviter les dépassements de capacités facilement.
• Supprimer ces maudits qualificateurs de type qui empoisonne les raisonnements sur le typage.
• Remplacer le qualificateur de type volatile par une directive du préprocesseur indiquant quand la « machine abstraite » doit être appliquée (par exemple #pragma ABSTRACT_MACHINE ON).
• Le qualificateur de type const deviendrait un attribut d'un identificateur et préciserait que l'objet qu'il référence ne peut être modifier et que son adresse ne peut être récupérée.
• Le qualificateur de type restrict deviendrait de même un attribut qui s'appliquerait à toute indirection effectuée via un pointeur donné.
• Supprimer la gestion des caractères larges qui est un échec cuisant.
• Ajouter un opérateur bitsof qui fournirait le nombre de bits de valeur composant un type.
• Ajouter des opérateurs maxof et minof qui donnerait respectivement le maximum et le minimum d'un type.
• En finir avec les trente-six mille types du genre int_least16_t, int_fast16_t, int16_t, etc. À ce sujet, rester le plus simple possible et fidèle à la représentation des entiers décrites dans la norme C89.
• Ajouter un type word qui équivaudrait au plus grand entier qui peut être stocké dans un registre du CPU suivant le mode dans lequel il se trouve ;
• Rationaliser les conversions implicites, parce que pour le moment, c'est pas la joie. D'ailleurs, pourquoi ne pas convertir la valeur de toute expression entière vers le type le plus grand ?
• Autoriser la définition d'une structure à l'aide du nom d'une ou plusieurs autres structures. Genre comme ceci.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

struct a {
    int x;
    int y;
};

struct b {
    struct a;
    int z;
};

/*
 * Revient en fait à écrire ceci.
 */
struct b {
    int x;
    int y;
    int z;
};

@Taurre: Je ne pense pas que les modifications sur les qualificateurs sera possible, les changements rendent le code incompatible. (restrict et volatile s'utilisent souvent en C ?)

Faut voir aussi que les mainteneurs de compilo et le comité sont plutôt frileux sur l'introduction de nouveaux mots clefs: cela peut casser du code. Au passage, les mots clef sont ajoutés en passant par les conventions des noms réservées (underscore suivit de majuscule) et l'ajout d'en-tête pour la forme lisse (ex: #define thread_local _Thread_local dans <thread.h>).

La suppression de type est aussi un problème. Les wchar_t sont pas mal utilisés et les types à taille fixe sont présent justement parce que la norme n'est pas très strict sur ce point. D'ailleurs, les types de taille exacte (intN_t) sont optionnels, car leur représentation non garantie.

C'est quoi des rotations de bits ? uint8_t(0x80) << 1 => uint8_t(0x01) ? Une fonction ne fait pas l'affaire ? J'ai l'impression qu'une fonction ferait aussi l'affaire pour maxof, minof (des macros existent), bitsof (que je ne suis pas sûr de comprendre) et la détection de dépassement. Avec _Generic, il y a moyen de faire.

Le dernier point proposé est intéressant, je le verrais bien en C++ aussi. Sinon, La plupart des compilos le supporte depuis longtemps sous forme d'extension (-fms-extensions pour gcc, -fms-extensions -Wno-microsoft pour clang et aucune idée de l'option pour msvc).

Pour le C++ je suis intéressé par

• Les ranges.
• la surcharge de l'opérateur ..
• Y aura-t-il d'autres opérateurs ? Voir (mais je rêve), la possibilité de créer ses propre opérateurs ?
• Le multi-dispatch (via la surcharge virtuel des paramètres virtual void S::foo(virtual S &))
• Autoriser en valeur de paramètre template les classes constexpr.
• Surcharge différente pour les paramètres constexpr (en gros, que foo(1) et int i; foo(i) appel des prototypes différents foo(constexpr int) et foo(int) par exemple).
• Des propositions pour faciliter la méta-programmation ? Il y a plein de lib mais, quand même.
• Le format de printf avec les flux c++. J'ai vu un jour une proposition, mais depuis plus rien.
• Que deviennent les propositions pour utilisé les instruction SIMD de façon transparente ? Cela est-il inclut dans les propositions ou politiques des nouveaux algorithmes (stl2 ?) ?

Lu'!

(1) D'après la présentation de Gabriel Dos Reis, ce n'est pas un remplacement au sens où les headers sont toujours nécessaires pour certaines tâches et au sens où l'on peut faire le choix de les utiliser quand on pense que c'est plus adapté.

(2) Pour ma part ce qui m'intéresse ici, c'est la question : est ce que le typeur va enfin cracher des messages buvables ? Et surtout est qu'il sera capable de nous dire avant instanciation qu'un template ne peut pas fonctionner ?

(3) Ce serait bien pour rendre les programmes vérifiables un jour .

(4) Alleluia si ça arrive (et il faut).

(1) Cela semble quand même compliqué au niveau du parseur, mais c'est vrai que pouvoir définir ses propres notations serait un sacré plus par rapport à ce que l'on peut faire actuellement.

(2) Oui, la présentation m'avait fait baver l'an dernier.

(3) Je préfère l'idée d'un printf("%1 lorem ipsum %[1.4]2 dolor amnet %3", v1, v2, v3).

Comme @lmghs je suis très intéressé par le support de la PpC et je me pose pas mal de question de ce côté : langage formel utilisé (quelle forme) ? compatible avec quelles logiques sans travaux supplémentaires ? logique d'ordres supérieurs ? (pour les algorithmes typiquement), qui va écrire les specs formelles pour l'existant ?

(1) Tant que l'on aura NCHAR_BIT et des plateformes où il peut valoir 32, on aura besoin de ces types. Quand on écrit du code qui doit s'interfacer avec des flux binaires, où lorsque l'on connait la capacité minimale dont on a besoin et que l'on veut aller vite ou économiser de l'espace, ces types servent.

(2) Je suis bien moins persuadé de la nécessité du WORD. Avec les compilos d'il y a 30 ans, je ne dis pas. Aujourd'hui ? C'est comme le Duff Device, on n'en entend plus parler. Tu as des cas d'application en tête (là, je n'ai que le memcpy et cie) ?

(3) J'ai découvert hier que char + char finissait obligatoirement dans un int… (J'ai du rajouter une fonctionnalité de promotion de types dans une lib qui doit compiler en C++98 et qui ne veut pas tirer de dépendance vers d'autres libs comme boost). Effectivement, il y a des trucs bizarres.

(1) Je pensais à ça aussi lors de mes premières expérimentations. Et puis … en C++14 il n'est plus nécessaire de borner les fonctions constexpr à ne faire que renvoyer une expression, et à devoir jouer avec la récursivité terminale. On a enfin droit à des boucles et autres structures de contrôles. Les fonctions doivent juste (/principalement ? – j'ai oublié) être pures. Du coup, je ne suis pas sûr qu'il soit vraiment nécessaire de supporter cela.

(2) Le standard ne cesse de s'enrichir en traits, mais il est vrai qu'il manque des choses de plus haut niveau, comme la possibilité de manipuler des expression booléennes sans avoir à taper des ::value (ou des ::Value avec les libs qui refusent le style de nommage du standard) dans tous les sens. La présentation de hana que j'ai vue pour les CppCon2015 était très intéressante.

(3) Oui. Ca serait bien. Je préfèrerai aussi que l'on ne supporte que le format montré par @Ksass`Peuk, mais la proposition voulait aussi supporter ces fichus formats du C (%d, %s, etc) qui ne servent à rien en présence de compilateur et des templates variadiques. -> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3716.html

Après, il existe diverses implémentations. Dont des qui jouent avec constexpr pour traiter le format et renvoyer des messages d'erreur.

Pour le format, je suis d'accord avec vous. Mais visiblement la proposition n'a pas bougé.

Les traits c'est bien, mais rien pour faire de la transformation par lot (les algorithmes de brigand, boost::mpl ou hana). Au passage, mettre hana en standard m'irait très bien :D.

Pour les '::value'/'::Value', il y a les valeurs templates et std::*_v ( http://en.cppreference.com/w/cpp/experimental/type_trait_variable_templates ). Ce qui accentue encore les différences avec les libs anti-nommage standard. Faut des alias partout :/.

(1) Je pensais à ça aussi lors de mes premières expérimentations. Et puis… en C++14 il n'est plus nécessaire de borner les fonctions constexpr à ne faire que renvoyer une expression, et à devoir jouer avec la récursivité terminale. On a enfin droit à des boucles et autres structures de contrôles. Les fonctions doivent juste (/principalement ? – j'ai oublié) être pures. Du coup, je ne suis pas sûr qu'il soit vraiment nécessaire de supporter cela.

Un exemple simple: 1_c -> std::integral_constant.

Impossible à faire avec une surcharge qui prend une valeur (/*que mettre ?*/ operator "" _c (unsigned long long);).

Et il faut minimum une centaine de lignes pour le faire avec template<char... c> parse_int<c...> operator "" _c ().

L'utilisation de valeur non constexpr empêche également l'utilisation de static_assert.

Au final, le problème apparaît quand le type de retour est influencé par les valeurs des types d'entrer. Actuellement, le meilleur moyen est de transformer une valeur en type comme dans les exemples de hana. Je trouve cela dommage.

(Oui je sais, c'est quand même particulier.)

En fait, les travaux sur les containers intrusive, noexcept et flat ont progressé ?

Je plussoie l'idée de Ksass pour un format de string "template". Un peu comme on peut voir en python

Je te rassure, l'idée n'est pas de moi.

Relativement relié : https://twitter.com/joel_f/status/656541490974498821 . Si vous avez des idées.

Le mot-clé volatile a son utilité et est présent dans certains programmes, oui. Par contre, restrict est complètement délaissé. Sinon, il serait possible de maintenir les qualificateurs un temps ou de permettre leur utilisation à l'aide d'une option ou encore de faire en sorte qu'il soit ignorer à l'aide d'une option.

Ouais, mais ils sont frileux pour ce qui veulent bien, hein. Ils nous ajoutent les merveilleux char16_t, char32_t, float_t et double_t, ils nous créent trente-six mille formats pour printf() et scanf() à ne plus savoir où donner la tête et ils incorporent des trucs qui n'ont rien à faire dans le corps d'un langage (à mes yeux, les threads n'ont pas à être traités dans la norme d'un langage, il s'agit de quelque chose qui doit être régler par la bibliothèque d'un système d'exploitation), mais ils rechignent à l'apparition d'un ou deux mot-clés…

Le plus souvent, dès qu'il est question de localisation ou d'internationalisation, c'est une bibliothèque tierce qui est utilisée, comme GNU gettext. Les wchar_t et les petits nouveaux char16_t et char32_t sont une plaie à utiliser et d'une franche inutilité dès que l'on veut quelques garanties.

Les types de tailles fixes sont effectivement optionnels, mais le sont, à mon avis, uniquement pour des raisons de compatibilité et pour la pureté des principes. En effet, quand on lit le paragraphe les concernant, on comprend très bien la direction que prend le comité en ce qui concerne la représentation des entiers.

La représentation est clairement définie et, à mon sens, c'est une erreur. S'il est incontestable que la représentation en complément à deux est pour ainsi dire la seule, je pense qu'un langage qui tente de s'abstraire de la machine comme le C ne doit pas faire de supposition aussi précise quant à la représentation de ses types. Plus la liberté laissée est grande, plus la portabilité suit.

C'est bien ça. Cependant, une fonction va réaliser cette opération en une multitude d'instructions alors que n'importe quel processeur dispose d'une instruction pour le faire les doigts dans le nez.

Malheureusement, non, il n'est pas possible d'obtenir les bornes d'un types signés sans engendrer un comportement indéfini. Essaye par exemple d'obtenir le maximum du type int sans recourir à la macroconstante INT_MAX.

EDIT : je reformule, essaye d'obtenir le maximum du type ptrdiff_t en C89 (donc sans la macroconstante PTRDIFF_MAX).

L'opérateur bitsof retournerait le nombre de bits de valeur composant un type entier. L'objectif est de connaître les bornes du type en excluant le bit de signe et les éventuels bits de bourrage. Ainsi, pour un type int « classique » de un bit de signe et de trente et un bits de valeur, l'opérateur retournerait trente et un.

Hmm… Tu peux préciser ta pensée ?

À mon avis, ces types sont une mauvaise réponse, pour les raisons que je développe plus haut. Dans le cas d'un flux binaires, la bonne solution consiste pour moi à utiliser un tableau d'unsigned char. Cela coûte en performance, mais c'est la seule qui est parfaitement portable.

EDIT : pas précisément, non. L'objectif premier était surtout de disposer d'un type qui permette de stocker le plus grand entier possible, comme intmax_t en C99, mais en plus clairement défini pour faciliter les liens avec l'Assembleur.

Rien qu'à voir la tête du paragraphe dédié aux conversions arithmétiques entre entiers tu comprends qu'il y a un problème.

C'est bien ça. Cependant, une fonction va réaliser cette opération en une multitude d'instructions alors que n'importe quel processeur dispose d'une instruction pour le faire les doigts dans le nez.

Ok, mais autant proposer tout un panel de fonction pour la manipulation de bit. Compter les bit à 1, etc. Si cela se fait à travers des opérateurs j'en serait très contant (raisons bassement égoïste: ils se retrouveront en c++ :D).

Pour _Generic:

1
2
3
4
5

#define maxof(x) _Generic((x), int: INT_MAX, long: LONG_MAX)

int main(){
  printf("%d %ld", maxof(0), maxof(0l));
}

Ce serait bien, en effet.

C'est une solution, mais incomplète. Que fais-tu pour le type ptrdiff_t ou n'importe quel autre type dont la correspondance n'est pas connue ? Une solution consiste à utiliser une suite d'opérateurs ternaire, comme ci-dessous, mais cela pose toujours problème étant donné que l'opérateur sizeof retourne le nombre de multiplets composant un type et non le nombre de bits de valeur qu'il utilise. Par exemple, dans le cas où deux types de base ont la même taille, mais qu'un à des bits de bourrage et pas l'autre, cette solution n'est d'aucun secours.

1
2
3
4
5
6
7
8
9

#define MAXOF(x) (sizeof(x) == sizeof(char)) \
    ? SCHAR_MAX \
    : (sizeof(x) == sizeof(short)) \
        ? SHRT_MAX \
        : (sizeof(x) == sizeof(int)) \
            ? INT_MAX \
            : (sizeof(x) == sizeof(long)) \
                ? LONG_MAX \
                : LLONG_MAX

(sans compter qu'il y a gros problème de typage avec cette solution, une expression conditionelle ne pouvant avoir qu'un type).

ptrdiff_t et les autres restes des alias sur des types natifs. Je ne ferrais rien de plus

Si vraiment ce n'est pas le cas:

1
2
3
4

#define maxof(x) \
  _Generic((x), int: INT_MAX, long: LONG_MAX, default: \
  _Generic((x), ptrdiff_t: PTRDIFF_MAX, default: \
  etc))

Bonjour,

Très bonne nouvelle pour les range. Ca va être bien pratique.

J'arrive trop tard et désolé si je suis complètement HS, mais j'ai quand même des questions tant qu'on parle du bordel des types numériques.

Pourquoi y a-t-il des types synonymes même sans compter les nombreux typedef genre int16_t ? je pense par exemple à long et int qui sont techniquement identiques, obligeant les compilateurs à ajouter le type long long pour les entiers 64 bits (qui n'est, en plus, d'après ce que je comprends, pas réellement standard même si tous les compilateurs le supportent aujourd'hui ou presque).

J'ai découvert à mon insu que ces nombreux types ont des implications tordues dans les templates notament, par exemple std::min(int, long) qui refuse de fonctionner sans un cast à la con. D'ailleurs pour std::min, pourquoi il n'est pas défini d'une façon similaire à la suivante en C++14 ? Ce serait bien arrangeant…

1
2

template<class T, class U> inline auto min (const T& a, const U& b) -> decltype(a+b) { return a<b?a:b; }
template<class T, class U, class... Z> inline auto min (const T& a, const U& b, Z... c)  -> decltype(min(a,min(b,c...)))  { return min(a, min(b, c...)); }

D'une façon plus générale, ce serait bien de tenir compte du type de la la lvalue dans les conversions implicites. Je ne sais pas dans quelles mesures c'est techniquement possible, mais voilà un petit exemple pour illustrer ma pensée (ça m'a valu une bonne partie de débogage) :

1
2
3

int x = 1;
unsigned long y = 0;
long long z = y - x; // Bah non, ça ne donne pas -1 !

Dans le même genre on a :

1
2

int x = 0x12, y = 0x34;
long long z = (x<<32) | y; 

Concernant le type word proposé ci-dessus, j'ai du mal à savoir si c'est une bonne idée, j'ai dû mal à voir quand il serait utile. Par contre le nom word est lui très mal choisi. En programmation windows on a déjà le type WORD qui est un alias pour unsigned short. ET non il ne faut pas supprimer le type wchar_t, il est indispensalbe sous windows si on programme en unicode.

Salut.

En réalité, long et int ne sont pas identiques. Et long long est standard depuis C++11. Cf ici.
Pour les différents typedef, ça permet de s'assurer d'avoir un type de la taille qu'on veut, pour s'interfacer avec des trucs qui attendent une taille précise. Comme int, long et compagnie ont une taille définie par l'implémentation, on ne peut pas les utiliser pour ça.

Quand je compile en 64bits, il arrive que sizeof(long) == sizeof(long long). long et int sont bien deux trucs différents.

Pour min et cie, il sauf savoir que le type de short + short est un int … Donc, ton écriture est loin d'être bonne. Mais les problèmes sont nombreux dans mes souvenirs. Sur les plus annexes, j'avais trouvé ça: https://akrzemi1.wordpress.com/2012/03/27/gotchas-of-type-inference/ Sur les plus profonds, il y a le fait que l'on ne peut plus retourner une référence si les types diffèrent.