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

du 19 au 29 octobre

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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é !

Alors, quelles questions aimeriez-vous poser au sujet de C et C++ ?

Disclaimer : ce post est une reprise modifiée de messages déjà postés sur un autre site communautaire francophone, à la demande et avec l'autorisation de l'auteur.

FYS : une bibliothèque C++ dans le domaine public

+10 -0

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.

Édité par lmghs

+0 -0

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

lmghs

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

http://nodraak.fr/ – Dictateur bienveillant de l'iTeam, logiciel libre et sécurité à l'ECE Paris

+1 -0

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 ?

It's harder to crack a prejudice than an atom. | Le mieux est l’ennemi du bien.

+0 -0

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

+1 -0
Staff

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;
};

Édité par Taurre

+3 -0

@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 ?) ?
+1 -0

Lu'!

    • (1) Modules (remplacement des hearders!);
    • (2) Concepts ;
    • (3) Undefined and Unspecified Behavior (simplification du langage) ;
  • (4) une ABI standardisée

germinolegrand

(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 :lol: .

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

  • 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 &))
  • Le format de printf avec les flux c++. J'ai vu un jour une proposition, mais depuis plus rien.

jo_link_noir

(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 ?

Édité par Ksass`Peuk

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein

+3 -0
  • 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 ?

Taurre

(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.

  • 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.

jo_link_noir

(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.

Édité par lmghs

+0 -0

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é ?

+0 -0
Staff

@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 ?)

jo_link_noir

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.

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>).

jo_link_noir

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…

La suppression de type est aussi un problème. Les wchar_t sont pas mal utilisés […].

jo_link_noir

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.

[…] 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.

jo_link_noir

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.

The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two’s complement representation.

ISO/IEC 9899:2011 (doc. N1570), § 7.20.1.1, al. 1

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 quoi des rotations de bits ? uint8_t(0x80) << 1 => uint8_t(0x01) ?

jo_link_noir

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.

J'ai l'impression qu'une fonction ferait aussi l'affaire pour maxof, minof (des macros existent)

jo_link_noir

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).

bitsof (que je ne suis pas sûr de comprendre)

jo_link_noir

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.

et la détection de dépassement. Avec _Generic, il y a moyen de faire.

jo_link_noir

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

(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.

lmghs

À 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.

(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) ?

lmghs

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.

(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.

lmghs

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. :p

Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:

  • If both operands have the same type, then no further conversion is needed.
  • Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
  • Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.
  • Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.
  • Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

ISO/IEC 9899:2011 (doc. N1570), § 6.3.1.8, al. 1

Édité par Taurre

+0 -0

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));
}
+0 -0
Staff

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).

jo_link_noir

Ce serait bien, en effet.

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));
}

jo_link_noir

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).

Édité par Taurre

+0 -0

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))
+0 -0

Cette réponse a aidé l'auteur du sujet

Hello!

Alors j'ai pu poser certaines de vos questions à un membre du comité, voici les réponses:

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++ ?

Ca a déjà été proposé pour C89 et C11, et la réponse est toujours la même: "utilisez C++ et pas C si vous voulez ce genre de fonctionnalités" :D

  • Inclure des opérateurs pour gérer les rotations de bits.

il n'y a plus vraiment de symbole de dispo pour de nouveaux opérateurs, et en ce qui concerne la rotation de bits, la question qui se pose est quid du support de la part des architectures? Des fonctions (lib) seraient plus adaptées.

  • Inclure un moyen pour détecter/éviter les dépassements de capacités facilement.

cela pourrait avoir une chance d'être ajouté (car cela ne modifie pas le langage) si quelqu'un écrit un papier dans ce sens :) cela pourrait consister à permettre de tester/réinitialiser le bit de status. Donc un papier est le bienvenue!

  • 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).

il faut d'abord voir ça du côté des auteurs de compilo car cela semble être une question d'optimisation du code. Quant à la possibilité d'annoter cette info dans le code via un #pragma, là aussi ça pourrait être accepté, à condition que quelqu'un présente et défende un papier :)

A noter qu'il semble qu'il y ait 3 français qui sont actifs au comité, et que si un 4eme les rejoins, alors il devient possible de monter un groupe officiel avec l'AFNOR, donc si ça vous intéresse de participer, c'est le moment! Le prochain meeting aura lieu à Londres (11-14 avril 2016).

  • Supprimer la gestion des caractères larges qui est un échec cuisant.

Ce n'est pas l'avis des japonais qui sont ceux à l'origine de cette ajout dans C (1995)

  • 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.

Il y a des travaux en cours pour ajouter des macros qui semblent aller dans ce sens. Voir le chapitre 13 "Integer width macros" du papier N1711: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1711.pdf

  • 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 ;

La personne à qui j'ai demandé pense que cette fonctionnalité existe déjà plus ou moins au niveau des compilos, mais que chaque compilo le fait à sa sauce. Donc oui ça pourrait être utile de le standardiser (mais avec le mot-clé _Word): faut soumettre un papier :)

  • Autoriser la définition d'une structure à l'aide du nom d'une ou plusieurs autres structures. Genre comme ceci.

Mon avis perso: cela ressemble très fort à de l'héritage de struct ce que tu proposes, autrement dit à incorporer des fonctionnalités de C++ dans C.

Voilà en ce qui concerne le C!

Quant à Ranges, ça n'avait pas été introduit en C++14, est-ce que le comité pense que cela sera bon pour C++17 ?

Aloqsin

Les Range ont été acceptées pour devenir un TS. Il y a de très fortes chances qu'ils soient dispo l'années prochaine en tant que tel. J'ai pu interviewer Eric Niebler sur le sujet, il était très content. Je publierait la vidéos dans quelques temps, vous pouvez souscrire à la mailinglist sur le site cpp-lang.io pour être tenu informé des interview publiées.

Édité par Aurelien RB

+10 -0

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.

Édité par QuentinC

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+0 -0

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).

QuentinC

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.

Mon Github | Mantra : Un Entity-System en C++

+1 -0

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.

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte