Rencontre avec le comité C++ : posez vos questions !

Version imprimable

Voir 40 message(s) de cette discussion en une page

21/10/2015, 09h53
prgasp77

Citation:

Envoyé par huguesacker

Pour moi, int64 est plus parlant que "long long" qui ne veut rien dire

Et pour moi, int est plus parlant que int32 ou int64 : dans 99% des cas je n'utiliserai qu'une fraction des valeurs représentables, et la seule chose qui m'intéresse au final c'est de savoir que j'utilise le type d'entier le plus adapté à l'architecture. Si j'utilisais int32 par défaut, mon code serait aberrant (et au passage, peu performant) sur une architecture 8 ou 16bits (et quelques arch 64bits exotiques).
21/10/2015, 10h00
Bousk

Citation:

Envoyé par huguesacker

LL [...] (de même que 'L' d'ailleurs); pourquoi ça ?

Euh... bah... L pour Long ? :weird:
21/10/2015, 16h25
huguesacker

standard

Citation:

À Bousk: Euh... bah... L pour Long ?

Je sais ce que cela veut dire, vous pensez bien ! Je dis simplement que (dans le nouveau standard dont on parle) quand une variable est bien identifiée, nativement il ne devrait pas y avoir besoin de L ou LL pour mettre la valeur dans la variable. Le compilateur sait comment générer le code qui va traiter la donnée dans la variable, donc il devrait être capable de lire le source puisqu'il génère le code machine qui va derrière.

Citation:

À prgasp77: Et pour moi, int est plus parlant que int32 ou int64 : dans 99% des cas je n'utiliserai qu'une fraction des valeurs représentables, et la seule chose qui m'intéresse au final c'est de savoir que j'utilise le type d'entier le plus adapté à l'architecture. Si j'utilisais int32 par défaut, mon code serait aberrant (et au passage, peu performant) sur une architecture 8 ou 16bits (et quelques arch 64bits exotiques).

Je n'ai jamais dit que je voulais un type int de 32 bits par défaut! Bien évidemment que l'on met la longueur adaptée! D'où char, ou short, etc. Mais on devrait avoir le droit nativement, plutôt que de passer par des inclusions (c'est bien de cela dont on parle): dans un nouveau standard, définir ses variables sans passer par des inclusions.

Citation:

À white_tentacle: 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...
Je crois qu’effectivement, tu as un retard de version assez important à rattraper en c++. La dernière version c’est C++14

Oui, j'ai vu le lien; j'y ai même répondu. Je connais très bien ces fichiers d'en-têtes, que l'on n'a pas le choix d'utiliser d'ailleurs.
La série des xxx_t fait appel au préprocesseur et à des inclusions, qui posent les problèmes dont on parle. J'aimerais des types NATIFS dans le langage (sans besoin d'en-têtes).
Pour finir, je vous rassure: nos connaissances et outils ne sont pas obsolètes; nos compilateurs sont récents, nous savons qu'on en est au cpp14, et notre savoir-faire vaut bien celui des autres.
Il me semble que dans une liste de choses qu'on voudrait dans un nouveau standard, chacun peut exprimer ce qu'il souhaite.
22/10/2015, 02h30
Aurelien.Regat-Barrel
Me voici donc à Hawaii, à assister aux discussions du comité. Je n'avais pas anticipé les 12h de décalage horaire, du coup hier soir j'ai manqué d'énergie pour aller à la pêche aux infos une fois les sessions de travail terminées :D

Ce matin j'ai appris qu'il y avait une proposition pour des typedef opaques, c.a.d des sous-types à la ADA:
http://www.open-std.org/jtc1/sc22/wg...15/p0109r0.pdf

C'est une vieille demande en C++ et même en C, à savoir faire en sorte que le code suivant ne compile pas :
Code:

1 2 3 4 5 6 7 8 typedef int X; typedef int Y; void setPoint(X x, Y y); X x = 10; Y y = 20; setPoint(y, x); // oups!
la proposition de ce matin a été rejetée de façon assez expéditive, et il y a peu de chances que quelque chose du genre soit un jour intégré à C++. En effet, il semble que ce soit un vieille demande, avant même C++ avec C. Et que ce qui parait initialement être plutôt trivial est en fait la porte ouverte à beaucoup de cas tordus à gérer, ce qui explique le système actuel.
22/10/2015, 02h49
Aurelien.Regat-Barrel

Citation:

Envoyé par huguesacker

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

Une bibliothèque réseau est en cours de standardisation (Boost ASIO), et pourrait même arriver avant C++17 sous forme de TS. Pour les graphismes, il y a un travail en cours sur une lib 2D. Je ne connais pas son status.
Pour une lib d'IHM graphique, c'est au delà des capacités du comité, d'autant plus que l'heure est à passer par une approche déclarative dans un autre langage donc (genre QML/Qt Quick en C++).

Citation:

Envoyé par 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

Effectivement c'est un concept bancal en général. C'est certes bien pratique, mais d'un point de vue performances c'est dramatique, parce que le mutex est verrouillé/déverrouillé autant de fois qu'il y a un accès au conteneur, au lieu d'avoir un mutex externe qui verrouille l'ensemble des accès, potentiellement pour d'autres conteneurs aussi.

Citation:

Envoyé par 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.

Cela dit, il y a des libs genre concurrent_vector de Microsoft qui propose ça (il me semble).
22/10/2015, 10h41
Luc Hermitte

Citation:

Envoyé par Aurelien.Regat-Barrel

Me voici donc à Hawaii, à assister aux discussions du comité. Je n'avais pas anticipé les 12h de décalage horaire, du coup hier soir j'ai manqué d'énergie pour aller à la pêche aux infos une fois les sessions de travail terminées :D

Ce matin j'ai appris qu'il y avait une proposition pour des typedef opaques, c.a.d des sous-types à la ADA:
[...]

la proposition de ce matin a été rejetée de façon assez expéditive, et il y a peu de chances que quelque chose du genre soit un jour intégré à C++. En effet, il semble que ce soit un vieille demande, avant même C++ avec C. Et que ce qui parait initialement être plutôt trivial est en fait la porte ouverte à beaucoup de cas tordus à gérer, ce qui explique le système actuel.

Hawaii? Profite bien !

Sinon, c'est dommage pour les types opaques. Au départ je croyais que using allait permettre cela, mais je fus bien déçu de découvrir que ce n'était pas le cas.
Il va falloir continuer à définir des structures triviales.
22/10/2015, 10h52
gb_68

Bonjour, tout d’abord merci pour ce fil de discussion :ccool:

Citation:

Envoyé par Aurelien.Regat-Barrel

la proposition de ce matin a été rejetée de façon assez expéditive, et il y a peu de chances que quelque chose du genre soit un jour intégré à C++.

Dommage :(. Sinon, il existe une autre proposition p0138r0.pdf sans doute plus légère qui se fonde sur les class enum, ceux-ci offrant déjà la plupart des caractéristiques d'un "strong typedef". Elle a eu/aura peut être un peu plus de chance.

Y-a-t-il déjà eu des discussions sur la "Unified call syntax" x.f(y) <-> f(x, y) ? Bjarne Stroustrup a l'air d'être à fond dessus, mais son impact sur l'existant me fait un peu peur. Depuis le C++11, la SFINAE a reçu un sacré coup de boost avec decltype ; l'on peut sélectionner une surcharge selon la validité d'une expression. La "Unified call syntax" risque donc de changer cela (exemple).
22/10/2015, 22h53
Aurelien.Regat-Barrel
Hello,

Citation:

Envoyé par gb_68

Y-a-t-il déjà eu des discussions sur la "Unified call syntax" x.f(y) <-> f(x, y) ? Bjarne Stroustrup a l'air d'être à fond dessus, mais son impact sur l'existant me fait un peu peur. Depuis le C++11, la SFINAE a reçu un sacré coup de boost avec decltype ; l'on peut sélectionner une surcharge selon la validité d'une expression. La "Unified call syntax" risque donc de changer cela (exemple).

Hier ils en ont parlé oui, mais j'étais avec un autre groupe. Apparemment ils ont débattu de savoir si :
- x.f(y) trouve f(x,y)
- f(x,y) trouve x.f(y)
- les deux
et ça serait la première option uniquement qui se serait dégagée. A priori, si je comprends bien, cette option est bien partie pour passer du groupe "evolution" (étude des proposition possibles) vers "core" (étude de son intégration). Mais tout ça dépend du vote de samedi je crois.

Il semble qu'il n'y ait pas d'inquiétude particulière sur la compatibilité avec le code existant.

Citation:

Envoyé par Aurelien.Regat-Barrel

Il semble qu'il n'y ait pas d'inquiétude particulière sur la compatibilité avec le code existant.

C'est ce point qui ne me rassure pas. La plupart des propositions sur le sujet affirment que la compatibilité descendante est complète (ex : p0131r0)

Citation:

This breaks no existing code. Cela ne casse aucun code exitant.

Seul la n4474 émet un bémol

Citation:

This proposal is backwards compatible (modulo SFINAE trickery, of course). Cette proposition est rétrocompatible (modulo les astuces SFINAE, bien sûr).

Or comme dans l'exemple de mon précédent message, avec decltype il est facile de tester la validité d'une expression et d'utiliser la SFINAE.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 template<typename T> void super_foo(const T & m) { std::cout << "super_foo gready function\n"; } template<typename T> void call_best_foo_impl(const T & m, int) { m.basic_foo(); } template<typename T> auto call_best_foo_impl(const T & m, bool) -> decltype(m.super_foo()) { m.super_foo(); } template<typename T> void call_best_foo(const T & m) { call_best_foo_impl(m, true); }
Avec la nouvelle règle, la fonction trop gourmande void super_foo(const T & m) va empêcher tout accès à la solution de repli basic_foo() comme c'est le cas en C++11/C++14.

23/10/2015, 15h29
Luc Hermitte

Citation:

Envoyé par Aurelien.Regat-Barrel

Ce matin j'ai appris qu'il y avait une proposition pour des typedef opaques, c.a.d des sous-types à la ADA:
http://www.open-std.org/jtc1/sc22/wg...15/p0109r0.pdf

Le sujet m'a inspiré: https://gist.github.com/LucHermitte/...9e1bc9fb486cea
N'hésitez pas à forker, améliorer, simplifier, ...
23/10/2015, 17h03
Iradrille
Citation:
Envoyé par Aurelien.Regat-Barrel

Hier ils en ont parlé oui, mais j'étais avec un autre groupe. Apparemment ils ont débattu de savoir si :

x.f(y) trouve f(x,y)
f(x,y) trouve x.f(y)
les deux

et ça serait la première option uniquement qui se serait dégagée. A priori, si je comprends bien, cette option est bien partie pour passer du groupe "evolution" (étude des proposition possibles) vers "core" (étude de son intégration). Mais tout ça dépend du vote de samedi je crois.

Il semble qu'il n'y ait pas d'inquiétude particulière sur la compatibilité avec le code existant.
Ca se passe comment niveau polymorphisme ?
Code:

1 2 3 4 5 6 struct Base { }; struct Derive : Base { }; void foo(Derive const&) { } Base *b = new Derive; b->foo(); // appel de foo(Derive const&) ? ou échec ?
Et niveau const-correctness ?
Code:

1 2 3 4 5 6 7 8 void foo(int const&) { } // oui je sais, une const ref sur int... void foo(int &) { } int const ci = 42; int i; ci.foo(); // foo(int const&) je suppose i.foo(); // ??
23/10/2015, 21h49
Aurelien.Regat-Barrel

Citation:

Envoyé par Luc Hermitte

Le sujet m'a inspiré: https://gist.github.com/LucHermitte/...9e1bc9fb486cea
N'hésitez pas à forker, améliorer, simplifier, ...

Note que tu peux juste forward déclarer "inline" tes types X_ et Y_:

Code:

using X = opaque<MyNonMath, struct X_>;

exemple en C++98 d'une solution que j'avais utilisé pour wrapper des appels SQL:
https://ideone.com/bJg1Yz

Citation:

Envoyé par gb_68

C'est ce point qui ne me rassure pas. La plupart des propositions sur le sujet affirment que la compatibilité descendante est complète (ex : p0131r0)Seul la n4474 émet un bémol

il y a sûrement des imperfections, mais il faut voir le bénéfice de cette proposition : simplifier l'écriture de code générique. Il y a tout un tas de wrappers de la STL qui devraient dégager. J'ai pu interviewer Bjarne ce matin là dessus, j'espère que tout est bien enregistré dans la vidéo !

Citation:

Envoyé par Iradrille

Ca se passe comment niveau polymorphisme ?

Et niveau const-correctness ?

c'est vraiment juste une histoire de résolution de nom: i.foo() cherchera si foo(i) compile, et si c'est le cas, c'est somme si tu avais écrit foo(i), c'est la même règle.

A toi de choisir la syntaxe que tu préfères : POO ou bien fonction libre. C'est une question de préférence à ce niveau.
Au niveau du code générique, le fait de pouvoir appeler les 2 avec la même syntaxe simplifie le code.
24/10/2015, 08h32
Iradrille
Citation:

Envoyé par Aurelien.Regat-Barrel

c'est vraiment juste une histoire de résolution de nom: i.foo() cherchera si foo(i) compile, et si c'est le cas, c'est somme si tu avais écrit foo(i), c'est la même règle.

A toi de choisir la syntaxe que tu préfères : POO ou bien fonction libre. C'est une question de préférence à ce niveau.
Au niveau du code générique, le fait de pouvoir appeler les 2 avec la même syntaxe simplifie le code.

Dac, ça va aussi permettre de faire quelque chose de similaire aux méthodes d'extensions en C# du coup.

La forme écrite sera privilégiée ? Ou se sera toujours la version POO / libre qui sera appelée quand c'est possible ?
Code:

1 2 3 std::vector<int> v; v.begin() // appel de std::vector::begin() ? std::begin(v); // appel de std::begin(std::vector) ?
24/10/2015, 21h00
Aurelien.Regat-Barrel

Oui tout à fait, il s'agit d'extension methods. L'approche C# a d'ailleurs été étudiée, mais sans plus.

De ce que j'en ai compris, ce qui a été accepté [comme première étape?] c'est seulement de trouver begin(v) quand on écrit v.begin(), mais pas l'inverse. Donc je suppose que le style d'écriture qui sera retenu est v.begin().
25/10/2015, 11h11
JolyLoic
Citation:
Envoyé par Aurelien.Regat-Barrel

Hier ils en ont parlé oui, mais j'étais avec un autre groupe. Apparemment ils ont débattu de savoir si :

x.f(y) trouve f(x,y)
f(x,y) trouve x.f(y)
les deux
Est-ce que tu sais s'il y a eu des discussions sur le multiple dispatch? Je sais que ce n'est pas la même proposition, mais je pense que si on a f(x, y) qui est virtuelle sur x, mais pas sur y, ça risque de ne pas être clair, et je me demande si ce n'est pas cet argument avant tout qui a bloqué le second point.
26/10/2015, 09h31
Luc Hermitte

J'image que c'est trop tard, toujours est-il que j'ai repéré une précondition excessive sur std::fill_n

Il est dit (draft 2014 N4296, et même dans le dernier 4527), que fill (et fill_n) requièrent que "value puisse être écrite dans l'ouput itérator (OI)".
Cela conduit à des vérifications dans la STL checkée de VC++ du style que "fill_n(nullptr, /*nb elems*/ 0, /*value*/42)" déclenche une assertion. (*)
Or pour un tel algorithme, la précondition devrait être que value puisse être écrite le range [OI, OI + max(0,n)) si non vide. La précondition courante est excessive (cas du range vide), et insuffisante (cas où OI + 1 est invalide, et n >= 2).

(*) Le cas d'utilisation qui conduit à ça est : un classe type vecteur, une fonction de remplissage, et des gens qui enchaine une construction par défaut et un remplissage. On pourrait supposer que c'est une erreur de programmation. Mais...

Autre scénario: On copie le vecteur vide vers un autre. Et on utilise std::copy(). Si on a pour précondition que output iterator (OI) doit être valide au lieu de [OI, OI + distance(first,last) ), pareil, on va claquer des assertions.
... Bon, std::copy, n'a pas de précondition sur la validité de l'itérateur de sortie. Juste qu'il ne doit pas appartenir à [first, last)

[Sinon, quel est le meilleur biais, maintenant que le meeting est fini, pour remonter cette interrogation ?]
27/10/2015, 12h11
Aurelien.Regat-Barrel

Citation:

Envoyé par JolyLoic

Est-ce que tu sais s'il y a eu des discussions sur le multiple dispatch? Je sais que ce n'est pas la même proposition, mais je pense que si on a f(x, y) qui est virtuelle sur x, mais pas sur y, ça risque de ne pas être clair, et je me demande si ce n'est pas cet argument avant tout qui a bloqué le second point.

Pas que je sache. Il y a plutôt eu des discussions relatives aux modules: x.f(y) ne trouve f(x, y) que si f(x, y) se trouve dans le module courant. Ce point sera à priori débattu de nouveau une fois que les modules seront dispo. Le fait d'avoir cette option fait perdre son intérêt aux extension methods.

Le statut actuel du papier (x.f() trouve f(x)) est de passer depuis Evolution vers Core. Autrement dit, il va être reformulé en vue d'étudier son intégration au prochain standard (il a passé le cap des propositions).

Citation:

Envoyé par Luc Hermitte

J'image que c'est trop tard, toujours est-il que j'ai repéré une précondition excessive sur std::fill_n

[Sinon, quel est le meilleur biais, maintenant que le meeting est fini, pour remonter cette interrogation ?]

Je pense que ton commentaire sera le bienvenue soit directement auprès de l'auteur soit, à priori, sur ce Google group:
https://groups.google.com/a/isocpp.o.../std-proposals

J'en profite pour donner une liste non exhaustive de papiers qui ont passé la cap de la proposition pour aller dans Core (afin d'étudier leur intégration au standard):
- Variables inline (N4424)
- ajout de __has_include (P0061R0)
- noexcept intégré au type des pointeurs de fonction (au même titre que const / volatile) (P0012R0)
- construction d'un strong enum type sans faire un cast (p0138r0). En fait je découvre qu'on peut déjà en C++11 faire un strong typedef sur un type intégral de cette manière:

Code:

enum class Index : uint32_t { }; // aucun enum !

ce papier permet de simplifier l'utilisation d'un tel type en supprimant la nécessité de la caster à l'initilisation
- spécification de l'ordre d'évaluation des arguments d'une fonction (n4228 révisé) => f(a, b, c) évaluera a, b, c dans cet ordre là. Apparemment, la norme ne spécifiait pas d'ordre pour permettre aux compilos une éventuelle optimisation qui en pratique n'aurait été implémentée nulle part.
- utilisation des lambdas en tant que constexpr (n4487)
- moins de restrictions sur l'initialisation des types agrégés (p0017r0) - cela permet de se passer d'écrire un nouveau constructeur quand une struct hérite d'une autre struct
- constexpr if (p0128r0) cela semble bien ressembler au static if de D. Dans le papier il est mentionné un mot clé spécifique (constexp_if) mais ce dernier point a été rejeté
- rendre "officielle" l'élimination de la copie des objets dans certains cas : typiquement une variable locale qui est renvoyée / lancée sous forme d'exceptions (p0135r0) - cela permet d'écrire un code légal qui s'attend explicitement à cette optimisation (donc sans constructeur de recopie)

voilà en aperçu. A noter que cela ne veut pas dire que ces changements seront dans C++17, mais qu'ils ont été acceptés pour y être intégrés si le groupe spécialisé dans cette tâche n'identifie pas de problème.

Enfin, deux papiers importants acceptés pour devenir des TS:
- modules
- STL range ! J'ai pu faire une interview d'Eric Niebler à ce propos :)

En tous j'ai pu faire une dizaine d'interviews, qui seront publiées au fur et à mesure (vous pouvez vous inscrire à la mailinglist ici si ça vous intéresse). En particulier, j'ai pu échanger avec Jean-Paul Rigault, un des rares français à avoir participé à la première norme de C++ et qui continue encore à suivre l'évolution du langage aujourd'hui.

Et vu qu'on commence à être un certain nombre à s'intéresser de près à l'évolution du langage, on pourrait peut-être voir pour monter un groupe dédié au sujet ? Car c'est comme cela qu'avait commencé la participation de la France il y a plus de 15 ans déjà !
27/10/2015, 13h28
ternel

Tant de nouvelles intéressantes!
Je croyais que dans certains cas, les lambdas pouvaient être des constexpr. Ce n'est pas le cas?
27/10/2015, 21h55
Aurelien.Regat-Barrel

Citation:

Envoyé par leternel

Je croyais que dans certains cas, les lambdas pouvaient être des constexpr. Ce n'est pas le cas?

D'après le papier, il semble que non.

A noter que, d'après les discussions, je n'ai pas bien compris s'il sera possible ou pas que constexpr soit implicite quand c'est possible, c.à.d qu'on n'ait pas besoin de le spécifier au niveau de la lambda. En tous cas ça a été débattu.
27/10/2015, 23h45
JolyLoic

Citation:

Envoyé par Aurelien.Regat-Barrel

- modules (sans la modularisation / contextualisation des macros, c.a.d qu'elles fonctionnent comme à l'heure actuelle)

Tu m'as fait très peur quand j'ai lu ça !
J'ai consulté les notes prises en réunion, et mon interprétation est fort heureusement différente !

Ce qui passe en Core, ce sont les modules avec la modularisation totale des macros, qui ne franchiront donc pas les frontières d'un module, ni dans un sens ni dans l'autre (c'est ce qui était proposé par Gaby). Par contre, plusieurs personnes pensent qu'une telle isolation est extrémiste, et que quelques macros, c'est une bonne chose (et que la manière proposée qui consiste à continuer avec des #include quand on ne veut pas de l'isolation n'est pas satisfaisante). C'est surtout une position défendue par les gens de Clang.

Du coup, l'idée est de ne pas mettre les modules dans C++17 même (trop risqué), mais de les mettre dans un TS spécifique. Pour l'instant, il contiendra la proposition de Gaby telle qu'elle est, mais il sera ouvert à l'ajout d'une mécanisme d'import/export sélectif de macro (pas l'immonde merdier qu'on a actuellement) qui reste à définir. La présence dans un TS devrait être suffisante pour que les compilateurs commencent à en proposer une implémentation.

Citation:

Envoyé par Aurelien.Regat-Barrel

Et vu qu'on commence à être un certain nombre à s'intéresser de près à l'évolution du langage, on pourrait peut-être voir pour monter un groupe dédié au sujet ? Car c'est comme cela qu'avait commencé la participation de la France il y a plus de 15 ans déjà !

Qu'entends-tu par là ? Tu sais qu'il y a quelques français qui participent régulièrement à ces discussions, et qu'on est en train de voir pour obtenir à nouveau la possibilité de voter lors des réunions. Tu voudrais faire quelque-chose autour de ça, ou bien tu as autre chose en tête ?

Voir 40 message(s) de cette discussion en une page