Discussion :

[prgasp77]

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

[Bousk]

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

Euh... bah... L pour Long ?

[huguesacker]

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

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

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

[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

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 :

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

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.

[Aurelien.Regat-Barrel]

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

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.

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

[Luc Hermitte]

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

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.

[gb_68]

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

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

[Aurelien.Regat-Barrel]

Hello,

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.

[gb_68]

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)

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

Seul la n4474 émet un bémol

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 :

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

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.

[Luc Hermitte]

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

[Iradrille]

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 :

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

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 :

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

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

[Aurelien.Regat-Barrel]

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 :

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

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

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 !

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.

[Iradrille]

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 :

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

1
2
3
std::vector<int> v;
v.begin() // appel de std::vector::begin() ?
std::begin(v); // appel de std::begin(std::vector) ?

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

[JolyLoic]

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.

[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 ?]

[Aurelien.Regat-Barrel]

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

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 :

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

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

[ternel]

Tant de nouvelles intéressantes!
Je croyais que dans certains cas, les lambdas pouvaient être des constexpr. Ce n'est pas le cas?

[Aurelien.Regat-Barrel]

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.

[JolyLoic]

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

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 ?