Discussion :

[Aurelien.Regat-Barrel]

Bonjour à tous!

Dans 10 jours (du 19 au 24), aura lieu une rencontre du comité de normalisation, 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++!

A cette occasion, je vais participer à ce meeting en tant que simple spectateur. Mon but est de suivre l'avancement des travaux et réaliser des interviews (video!) de membres du comité. L'idée est de célébrer 30 ans de travail d'une part, et améliorer les échanges entre le comité et la communauté, c'est-à-dire vous et moi!

Et je vous propose de partager ici vos questions à propos du C++ : quelles questions aimeriez-vous poser au comité ? Quels sujets aimeriez-vous voir être abordés ?

A ce jour j'ai prévu de faire de mon mieux pour obtenir des détails sur :

• 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 fonctionalités

J'espère aussi pouvoir échanger autour des travaux en cours sur le développement de guidelines "officielles" et autres efforts qui vont dans ce sens. Et je compte partager mon sentiment qu'une meilleure présentation et exposition des travaux du comité est nécessaire, afin que les non experts puissent se faire une idée de ce qui se passe.

Enfin, et c'est pas rien : je souhaite mettre des visages sur ces hommes et femmes qui font évoluer le langage, et recueillir leur vision sur cette aventure qui dure depuis plus de 30 ans !

Et vous ?

Qu'est-ce qui vous intéresse en particulier ?

[Luc Hermitte]

Bonne initiative.
Pas vraiment des questions. Mais je suis fort intéressé par le support de la PpC. Et pas juste à coup d'asserts, même si c'est déjà un début. Ce que j'avais vu passer au sujet d'un éventuel support par le compilateur était alléchant. Dans les personnes impliquées, il y a Gaby, John Lakos.et quelques autres. Si j'ai bien suivi une conf de Gaby lors de la CppCon2015 devait traiter le sujet, mais la video n'est pas encore sortie, ni les slides.

Après, j'imagine que ce n'est pas l'endroit pour des questions mineures comme à quand un <stringfwd> ? (NB: je n'ai pas regardé si entre temps c'était dans le C++17, vu qu'il y a déjà des surprises comme std::size())

[sinasquax]

Un static if est il prévu pour la métaprogrammation ?

[archqt]

Bonne initiative.
Pas vraiment des questions. Mais je suis fort intéressé par le support de la PpC. Et pas juste à coup d'asserts, même si c'est déjà un début. Ce que j'avais vu passer au sujet d'un éventuel support par le compilateur était alléchant. Dans les personnes impliquées, il y a Gaby, John Lakos.et quelques autres. Si j'ai bien suivi une conf de Gaby lors de la CppCon2015 devait traiter le sujet, mais la video n'est pas encore sortie, ni les slides.

Après, j'imagine que ce n'est pas l'endroit pour des questions mineures comme à quand un <stringfwd> ? (NB: je n'ai pas regardé si entre temps c'était dans le C++17, vu qu'il y a déjà des surprises comme std::size())

PpC c'est quoi ? Merci

[Ehonn]

Programmation par Contrat (?)

[JolyLoic]

C'est l'endroit pour toutes les questions, majeures comme mineures. Les questions majeures font l'objet de papiers spécifiques, les mineures entrent dans la catégorie "issue" comme par exemple http://www.open-std.org/jtc1/sc22/wg...wg-active.html, mais les deux sont discutées lors des réunions (même si sur certains sujets, des réunions spécifiques existent pour avancer le travail, ce n'est que lors des réunions officielles que les décisions sont prises).

Maintenant, sur <stringfwd>, je ne suis pas certain que ce soit un point entièrement mineur. Il pose la question d'un <vectorfwd>, d'un <memoryfwd>, voire d'un <stdfwd> ainsi que le retour du <std> (globalement, tout le monde était d'accord d'avoir un header <std> avec les éléments essentiels de la bibliothèque, mais personne n'était d'accord quant à son contenu).

Je me pose en particulier une question : Souvent, mes strings ne se retrouvent pas uniquement comme paramètres de fonction, mais aussi comme données membre. Du coup, je ne crois pas que j'aurais beaucoup d'utilités à un <stringfwd>, même si j'en avais un à ma disposition.

[JolyLoic]

A cette occasion, je vais participer à ce meeting en tant que simple spectateur. Mon but est de suivre l'avancement des travaux et réaliser des interviews (video!) de membres du comité. L'idée est de célébrer 30 ans de travail d'une part, et améliorer les échanges entre le comité et la communauté, c'est-à-dire vous et moi!

Pour information, il est interdit de filmer les discussions elles-mêmes, afin de préserver la liberté de parole de chacun pendant ces discussions. Maintenant réaliser des interviews à côté est toujours possible, mais les semaines de réunions sont généralement très chargées. As-tu déjà contacté des personnes pour leur demander s'ils acceptaient ? As-tu des noms en tête ?

[alecool]

Lors de la cppcon 2014 (il me semble) il avait été mentionné (par Herb Sutter ou Stroustrup, je ne sais plus) la volonté d'impliquer plus les entreprises dans l'évolution de la bibliothèque standard, en particulier l'ajout de nouveaux domaines fonctionnels. Il me semblait avoir compris que l'objectif était de faire proposer des bibliothèques complètes par des entreprises pour normalisation, dans le but d'étendre plus rapidement la portée de la bibliothèque standard (ça, c'est pour le contexte de la question mais il faudra que je retrouve la source...).
Ma question : qu'en est-il de cette initiative? Des propositions ont-elles vues le jour? La proposition de librairies "complètes" fait-elle partie du processus de standardisation?

[Luc Hermitte]

PpC c'est quoi ? Merci

Oui. C'est bien la programmation par contrat. J'y ai consacré trois billets dans mon blog -- le dernier (des snippets essentiellement) a été accouché il y a peu.

[Luc Hermitte]

Ensemble d'autres points mineurs auxquels je peux penser:
- Un support prévu pour des named parameters ? (NB: il y a eu plein de feintes de type bibliothèque depuis le C++11)
- stoi, stod, etc sont intéressants, mais pourquoi n'a-t-on pas vu un sto<T> ?
- Qu'en est-il de std::is_contiguous ? (J'avais vu passer une proposition pour sa définition, mais plus rien depuis)

[Luc Hermitte]

final, corrigez-moi si je me trompe, s'applique à tous les héritages.
Pour les classes à sémantique de valeurs, il pourrait être extrêmement pertinent vu qu'elles se combinent très mal avec l'héritage public et le LSP d'une certaine façon. Tant au niveau sémantique, qu'au niveau syntaxico-technique (cf le slicing). Seulement, le C++ a cette étrange bête qu'est l'héritage privé : un héritage qui ne permet que d'importer du code, vu qu'il ne permet pas la substituabilité syntaxique. Un héritage qui nous permet, nous développeurs fainéants, de dériver une sorted_list d'une list sans encourir d'écrire des aberrations. Seulement voilà, alors qu'il serait intéressant de flagguer std::list comme finale, on ne peut pas le faire sans interdire "class sorted_list : /*private*/ list".

Quid d'un final qui autoriserait l'héritage privé ?
(Oui, des fois, j'ai des idées tordues.)

[Aurelien.Regat-Barrel]

Bonjour !

Bonne initiative.
Pas vraiment des questions. Mais je suis fort intéressé par le support de la PpC. Et pas juste à coup d'asserts, même si c'est déjà un début.

Ca me surprend pas de toi Ironiquement, je crois que les premières versions de C++ avaient un tel mécanisme (des fonctions membres appelées automatiquement pour valider les invariants), mais B. S. les a retiré car... il était le seul à les utiliser

Lors de la cppcon 2014 (il me semble) il avait été mentionné (par Herb Sutter ou Stroustrup, je ne sais plus) la volonté d'impliquer plus les entreprises dans l'évolution de la bibliothèque standard, en particulier l'ajout de nouveaux domaines fonctionnels. Il me semblait avoir compris que l'objectif était de faire proposer des bibliothèques complètes par des entreprises pour normalisation, dans le but d'étendre plus rapidement la portée de la bibliothèque standard (ça, c'est pour le contexte de la question mais il faudra que je retrouve la source...).
Ma question : qu'en est-il de cette initiative? Des propositions ont-elles vues le jour? La proposition de librairies "complètes" fait-elle partie du processus de standardisation?

Cela va tout à fait dans le sens des questions que je veux poser sur comment donner plus de possibilité à la communauté (et plus spécifiquement les entreprises) pour soutenir le langage sans avoir à s'impliquer dans un processus aussi lourd que l'ISO. J'ai ma propre idée à suggérer.

Pour information, il est interdit de filmer les discussions elles-mêmes, afin de préserver la liberté de parole de chacun pendant ces discussions. Maintenant réaliser des interviews à côté est toujours possible, mais les semaines de réunions sont généralement très chargées. As-tu déjà contacté des personnes pour leur demander s'ils acceptaient ? As-tu des noms en tête ?

je sais J'ai déjà assisté un à rencontre "informelle" en février à Cologne, où j'ai pu me roder, prendre des contacts et même faire 2 d'interview (pour me chauffer). Là j'ai un meilleur matos et suis mieux préparé... et je suis en contact avec pas mal de monde, à commencer par B. Stroustrup, H. Sutter, et d'autres moins connus. Car mon idée c'est aussi de montrer les "anonymes" qui sont derrière C++ (ils sont nombreux!)

Ensemble d'autres points mineurs auxquels je peux penser:
- Un support prévu pour des named parameters ? (NB: il y a eu plein de feintes de type bibliothèque depuis le C++11)
- stoi, stod, etc sont intéressants, mais pourquoi n'a-t-on pas vu un sto<T> ?
- Qu'en est-il de std::is_contiguous ? (J'avais vu passer une proposition pour sa définition, mais plus rien depuis)

Les named parameters intéressent pas mal de monde semble-t-il, car c'est dans ma liste de questions recueillies sur un forum anglophone. Il semblerait que ça ait déjà été débattu et + ou - rejeté. Je vais essayé d'en savoir plus. Pour les autres points aussi précis, je vous promets rien... mais je vais voir !

final, corrigez-moi si je me trompe, s'applique à tous les héritages.
Pour les classes à sémantique de valeurs, il pourrait être extrêmement pertinent vu qu'elles se combinent très mal avec l'héritage public et le LSP d'une certaine façon. Tant au niveau sémantique, qu'au niveau syntaxico-technique (cf le slicing). Seulement, le C++ a cette étrange bête qu'est l'héritage privé : un héritage qui ne permet que d'importer du code, vu qu'il ne permet pas la substituabilité syntaxique. Un héritage qui nous permet, nous développeurs fainéants, de dériver une sorted_list d'une list sans encourir d'écrire des aberrations. Seulement voilà, alors qu'il serait intéressant de flagguer std::list comme finale, on ne peut pas le faire sans interdire "class sorted_list : /*private*/ list".

Quid d'un final qui autoriserait l'héritage privé ?
(Oui, des fois, j'ai des idées tordues.)

Ben je crois que y'a un GOTW qui dit que ce genre d'héritage privé est à éviter au profit de la composition... On m'a suggéré aussi de demander la possibilité de facilement créer des décorateurs à la python, apparemment adapté à la fois à ce genre de chose mais aussi pour la PPC. Mais moi je connais pas assez python...

[r0d]

Bonjour,

je ne suis plus vraiment l'actualité du C++ depuis C++11 donc je vais probabement dire une bêtise, mais qu'en est-il des conteneurs thread safe (list, vector, queue, ...)?
Car j'ai vendu mon âme au diable et je pratique actuellement plus le C# que le C++, et j'avoue que les conteneurs thread safe du C# apportent un confort tout à fait acceptable pour un développeur fainéant de mon espèce.

[Luc Hermitte]

Plus je réfléchis à la question, plus je me dis que la notion de conteneur thread safe ne tient pas la route car notre besoin sera toujours subtilement différent. Et que l'on ne veut certainement pas locker chaque accès en R ou W sur un conteneur -- la contention, c'est mal. Sans parler de la granularité (peut-on écrire v[0] pendant qu'on lit v[1] et v.back().). Et quid de l'ajout, des invalidations? C'est plutôt des mécanismes de synchronisation plus précis dont on a besoin -> patterns Objet Actif et Queues de Messages. D'ailleurs, l'implémentation de queue (de messages) en standard serait un plus (on en a vu fleurir plus d'une suite au C++11, dont par Anthony Williams), mais côté standardisation il me semble n'avoir rien vu.


Pour en revenir à l'héritage privé, bien sûr que la composition offre plus de souplesse. Mais elle nécessite l'écriture de boiler plate code pour les cas où un couplage fort est tolérable (mon exemple de list et sorted_list n'était pas innocent). Ou alors, il nous faudrait des moyens pour faire de la délégation sans valeur ajoutée. Genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template <typename T>
class sorted_list final
{
public:
...
   using m_list.size() const; // ou m_list::size;
   using m_list.cbegin() const;
   using m_list.begin() const;
   ... 
   using m_list.empty() const;
...
private:
   list<T> m_list;
};

EDIT:
Bon, on pourrait imaginer ce genre de choses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#define DELEGATE_TO(fname, attribute)                          \
    auto fname() const noexcept(noexcept(attribute.fname())) { \
        return attribute.fname();                              \
    }
 
 
template <typename T>
class sorted_vector final
{
public:
    sorted_vector() = default;
    sorted_vector(std::initializer_list<T> init)
        : m_vector(init)
        {
            std::sort(m_vector.begin(),m_vector.end());
        }
 
    DELEGATE_TO(cbegin, m_vector);
    DELEGATE_TO(cend  , m_vector);
    DELEGATE_TO(begin , m_vector);
    DELEGATE_TO(end   , m_vector);
    DELEGATE_TO(size  , m_vector);
    DELEGATE_TO(empty , m_vector);
 
private:
    std::vector<T> m_vector;
};

Mais bon. C'est tout pourri. Et cela ne gère pas la délégation de fonctions à paramètres -- sans rajouter des arguments à la macro, déléguez donc à m_vector.swap(), ou à m_vector[i]. Ou alors, il faut tout templatiser, ce qui n'est pas trop top pour les messages d'erreurs qui seront produits.

[white_tentacle]

Pour en revenir à l'héritage privé, bien sûr que la composition offre plus de souplesse. Mais elle nécessite l'écriture de boiler plate code pour les cas où un couplage fort est tolérable (mon exemple de list et sorted_list n'était pas innocent). Ou alors, il nous faudrait des moyens pour faire de la délégation sans valeur ajoutée. Genre:

Eiffel a introduit la notion de « non-conforming inheritance ». On hérite de l’interface publique, mais on n’est pas substituable (ça évite par exemple le problème du destructeur virtuel). En ce qui me concerne, j’ai quelques cas où j’aurais une utilité pour ça (typiquement, classes paramétrable héritant de leur type paramétré pour y ajouter des comportements). C’est à ce genre de choses que tu penses toi aussi ?

Sinon, comme toi, j’ai de grosses attentes sur la PpC, et les vérifications statiques qui vont avec. La présentation d’Herb Sutter donnait un très bon avant-goût, j’attends aussi celle de Gabriel Dos Reis.

[Luc Hermitte]

Je ne connaissais pas (/avait oublié?) la notion de « non-conforming inheritance ». J'aime. Merci pour l'info.

Sinon, oui on va retrouver le même genre d'idées même si mes cas d'utilisation sont plus dans la lignée de "la délégation marcherait aussi, mais je n'ai pas envie d'écrire du code inintéressant et facile à foirer".

[huguesacker]

Bonjour,
C'est sans doute trop tard pour la question, mais comme beaucoup, j'aimerais voir apparaître des choses vraiment pratiques, plutôt que des abstractions hyper complexes.
- Définir des types de variables standards:
int16, int32, int64, int128 avec bien entendu, le pendant unsigned (au choix, byte, uchar, uint32, etc).
Oui je sais, on peut les définir, mais cela passe par des méandres (assez) complexes, parceque les machines n'ont pas la même longueur de mot. Dans les codes sources, on se ramasse avec des stupidités genre "long long"..
Pouquoi ne pas définir des types standards! J'aimerais aussi des grands nombres (entiers, flottants, réels).
- De la même façon qu'on a eu: #include<stdio> et la série des printf(..) et autres scanf(..) etc. à l'époque où les ordis ne faisaient que du texte, il faudrait:
#include<interface> permettant de gérer des fenêtres et des composants de base: case à cocher, etc.
#include<graphics> permettant de faire des draw_rect(..) et autres line(..) etc. sur écran/fenêtres, et imprimante graphique.
#include<networks> permettant de faire du réseau. Autres idées: support de utf8 etc.
Les termes #include ne sont que des exemples; on pourrait avoir aussi "using graphics;" ou "uses" ou "module" ou autre plus approprié.

Bien entendu, je ne dis pas qu'on ne peut pas déjà le faire avec C/C++, mais on doit passer par des bibliothèques/installs, et on devrait pouvoir le faire de base, à un certain niveau. Cela n'empêche pas le développeur d'utiliser autre chose s'il veut des outils plus performants/adaptés à son besoin. Le succès de java est dû en grosse partie au fait qu'il vient avec ce type de bibliothèque ou possibilité. Si C/C++ vient aussi avec cela, il y aura un nouvel engouement pour notre langage. Il faudrait que les autorités comprennent que les abstractions c'est bien, mais les développeurs sont encore plus intéressés par des nouveautés vraiment pratiques et qui les aident, plutôt que des abstractions qui ne servent qu'à une minorité.
Voilà, scusez le retard.

[Bousk]

Bonjour,
C'est sans doute trop tard pour la question, mais comme beaucoup, j'aimerais voir apparaître des choses vraiment pratiques, plutôt que des abstractions hyper complexes.
- Définir des types de variables standards:
int16, int32, int64, int128 avec bien entendu, le pendant unsigned (au choix, byte, uchar, uint32, etc).
Oui je sais, on peut les définir, mais cela passe par des méandres (assez) complexes, parceque les machines n'ont pas la même longueur de mot. Dans les codes sources, on se ramasse avec des stupidités genre "long long"..
Pouquoi ne pas définir des types standards! J'aimerais aussi des grands nombres (entiers, flottants, réels).

Et cstdint ?

[huguesacker]

Et cstdint ?

Oui, c'est ce que je disais: on peut faire mais en passant par des inclusions et autres arcanes. Me semble que cela devrait être dans les types standards (de chez standard, avec des longueurs standardisées sur les divers compilateurs), tout comme les grands nombres, ainsi que les matrices. Pour moi, int64 est plus parlant que "long long" qui ne veut rien dire, sans parler des "LL" après les valeurs données.. (de même que 'L' d'ailleurs); pourquoi ça ? Tout cela donne de la lourdeur, pénalisante pour rien. Il serait bien de régler le problème des printf etc. qui sont soi-disant unsafe.
Et une fois qu'on aura une vraie interface, une bib graphique et du réseau, beaucoup de monde abandonnera java pour C++.

[white_tentacle]

Oui, c'est ce que je disais: on peut faire mais en passant par des inclusions et autres arcanes. Me semble que cela devrait être dans les types standards (de chez standard, avec des longueurs standardisées sur les divers compilateurs), tout comme les grands nombres, ainsi que les matrices. Pour moi, int64 est plus parlant que "long long" qui ne veut rien dire, sans parler des "LL" après les valeurs données.. (de même que 'L' d'ailleurs); pourquoi ça ? Tout cela donne de la lourdeur, pénalisante pour rien. Il serait bien de régler le problème des printf etc. qui sont soi-disant unsafe.
Et une fois qu'on aura une vraie interface, une bib graphique et du réseau, beaucoup de monde abandonnera java pour C++.

Tu as lu le lien qui est donné ?

std::int64_t c’est pas parlant ?

cstdint ce sont des arcanes ?

Faudrait voir à pas exagérer...

Voilà, scusez le retard.

Je crois qu’effectivement, tu as un retard de version assez important à rattraper en c++. La dernière version c’est C++14 .