[ISOC++] Mailing pre-Bristol

Hop, les papiers pour la réunion de Bristol du comité ISO sont tombés :

http://open-std.org/jtc1/sc22/wg21/d...mailing2013-03

Enjoy !

8O 8O 8O
C'est quoi ce tsunami de papiers !?
Il y a en plus de 100 dans ce mailing, c'est du jamais vu, d'habitude ça tourne autour de 20-50.
Ils vont avoir du pain sur la planche à Britstol pour éplucher tout ça. :mrgreen:

Citation:

---

Envoyé par Joel F

Hop, les papiers pour la réunion de Bristol du comité ISO sont tombés :

http://open-std.org/jtc1/sc22/wg21/d...mailing2013-03

Enjoy !

---

Ah ! De la lecture ! Je m'ennuyais fermement moi ! :)

J'ai déjà repéré des trucs intéressants (std::integer, par exemple ; même si dans ce cas spécifique, je trouve le design de la classe étrange, et pour certains points contre-productif).

Je vais jeter un coup d'oeil à tout ça rapidement :)

Depuis une semaine ça ne cesse de pleuvoir, j'ai eu du mal à tout éplucher :D

Citation:

---

Envoyé par germinolegrand

Depuis une semaine ça ne cesse de pleuvoir, j'ai eu du mal à tout éplucher :D

---

Je t'aide :

• "Proposal for Unbounded-Precision Integer Types" : (types entiers de taille arbitraire) l'idée est bonne, mais la réalisation est à revoir (malgré tout le respect que j'ai pour Pete Becker). Un des points qui me pose problème est le fait que le type std::integer proposé n'est pas liée à un allocateur. Du coup, impossible de contrôler la manière dont la mémoire est allouée. Hors, tel que je le vois, c'est un point nécessaire qui, en outre, ne pose pas de difficulté majeure (Pete Becker semble penser que si). En outre, la présence d'une fonction std::integer::compare() ne me plait pas trop - notamment sur son fonctionnement à la strcmp().
• "C++ Latches & barriers" : plutôt une bonne chose ; me fait penser au fait que la librairie C++ n'a pas de classe semaphore<>, plus générique des ces deux classes.
• "Pass by Const Reference or Value" : le point soulevé est intéressant (en gros, problème en cas d'aliasing - si une fonction prends deux argument, un en ref, l'autre en const ref, l'argument en ref peut en fait pointer sur le const ref ou sur une partie de celui-ci. Exemple:

Code:

---

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

struct A { int a, b; int sum() const { return a + b; } int product() const { return a * b; } }; int func(int& out, const A& in) { out = in.product(); return out + in.sum(); } // ... A a = { 2, 5 }; int& aa = a.a; std::cout << func(aa, a); // meh ?

---

.

• "s/bound/extent/": clarification de la sémantique du texte de la norme. Toujours bon.
• "Introducing Object Aliases" : il y a définitivement quelque chose à creuser de ce coté. L'idée est de pouvoir créer des constantes template grâce à la syntaxe using.

Code:

---

1 2 3 4 5 6 7 8

template< class T = double > struct pi_constant { static constexpr T value = static_cast<T>(3.141592653589793L); };   template< class T = double > using auto pi = pi_constant<T>::value;

---

• "A Parallel Algorithms Library": [codeinline]std::sort(std::par, v.begin(), v.end())[codeinline], c'est plutôt une bonne idée. Je comprends le principe et l'exécution. Ceci dit, ça fait dépendre la librairie standard non pas du coeur du langage, mais d'une technologie proposée ou non par le compilateur (en l'occurence, OpenMP, vu la proposition). A proposer sous la forme d'une feature optionnelle ? Par contre, sur la version vectorisée, je suis encore plus circonspect - la vectorisation dépends non seulement d'une technologie de compilation, mais aussi de features du processeur. La, ça me semble vraiment hasardeux (sans compter que les points comme l'alignement, l'aliasing... ne sont pas suffisament traités).
• "Proposing a C++1Y Swap Operator" : meh ? ça, ça me semble tiré par les cheveux. Autant std::swap est lisible, autant operator:=: me semble peu lisible. Peut être sous une autre forme (operator>< ? cet opérateur a l'avantage d'être symétrique, comme le premier, et d'indiquer un mouvement).
• "Conditionally-supported Special Math Functions for C++14" : sur l'utilisation d'une tournure particulière pour réintégréer les fonctions de math spéciales dans C++14 en les rendant optionnelles. Me parait être un bon compromis.
• "Unicode Support in the Standard Library" : non ; selon moi, la vrai solution au problème de l'unicode est un type de donnée spécialisé représentant un code point (en UTF8, un u8 ; en UTF16, un u18, en UTF32, un u32), et des classes std::basic_string<> spécialisées. L'introduction d'une classe std::encoded_string ne va faire que compliquer les programmes, en multipliant le nombre de types "chaines" alors qu'un seul est nécessaire (d'autant plus qu'il existe déjà, et est largement utilisé).
• "Proposing the Rule of Five" : les développeurs C++ partent du principe que certaines fonctions membre spéciales sont automatiquement générées par le compilateur. Cette proposition veut empêcher ce fonctionnement dès lors qu'un des big five est déclaré. C'est à mon sens une erreur (et un cauchemar en terme de maintenance). Un nouveau standard C++ ne doit pas être incompatible à ce point avec les standards existants (même si, effectivement, il y a des incompatibilités entre C++98 et C++11 ; mais celles-ci ne sont pas si courante que ça).
• "Return type deduction for normal functions" : dans le principe, je suis tout à fait d'accord. Il s'agirait de laisser le compilateur décider du type de retour d'une fonction lorsque le programmeur spécifie que ce type est auto. Aujourd'hui, on est obligé d'utiliser decltype à la suite pour que le compilateur connaisse le type de retour, et l'auteur montre que le compilateur peut tout à fait le détecter lui-même dans de nombreux cas.
• "make_unique" : oui ; ça parait même évident, une fois formulé.
• "std::split(): An algorithm for splitting strings" : moui. Peut-être.
• "std::join(): An algorithm for joining a range of elements" : c'est déjà plus intéressant.
• "A Three-Class IP Address Proposal" : ce sont les classes IP de Asio. Leur design a été longuement refléchi, et il est plutôt correct selon moi. Un seul point noir : je ne peux pas écrire le code suivant

Code:

---

1 2 3 4 5 6 7 8 9

void func(const ip::address_v4& ipv4) { ... } void func(const ip::address_v6& ipv4) { ... }   // ... ip::address ip = "::1"; func(ip); // erreur de compilation

---

• ""Static If" Considered". Bjarne ne veut pas de static if dans son langage. Ses arguments (enfin, pas que les siens) sont clairs. Entièrement d'accord avec lui.
• "Network byte order conversion" : htons, ntohs et consort (plus deux fonctions template hton<> et ntoh<>). Dès lors qu'on ajoute un support réseau, cette proposition devient nécessaire. Il y a quelques petits points à revoir (pourquoi ajoute-t-on des spécialisation pour les unsigned-integral uniquement ? Les signed-integral n'ont pas le droit de passer par le réseau ?). Aussi, une fonction hton<T> quelque soit T, c'est un peu osé (que se passe-t-il si T == std::vector<std::map<std::string, void*>> ?). La proposition ne dit rien sur le sujet (la solution évidente est d'interdire toute instanciation à partir d'un type non scalaire (je ne vois pas pourquoi je ne pourrais pas faire un ntoh<float>() ; après tout, on transfère des données sur le réseau).
• "Extending std::search to use Additional Searching Algorithms" : je suis pour. Le proposal est clair, et son bénéfice immédiat - le tout pour 4 fonctions ajoutées dans la librairie standard + un overload de std::search. Tout est ensuite dans la balance mémoire/rapidité, et le choix final reviens au programmeur. C'est brillant.
• "Literal operator templates for strings" : a du sens. Certains exemples sont plus forts que d'autres (notamment l'exemple Qt ou l'exemple d'obfuscation). Oui, les user litteral doivent pouvoir être définis sous la forme d'operateurs template (ce n'est pas le cas à l'heure actuelle).
• "Wording for Accessing Tuple Fields by Type" : oui. Ok. Peut-être.

Bien évidemment, ce n'est qu'un première réflexion, avec une lecture en diagonale.

Citation:

---

Envoyé par Emmanuel Deloget

Je t'aide :

• "A Parallel Algorithms Library": Par contre, sur la version vectorisée, je suis encore plus circonspect - la vectorisation dépends non seulement d'une technologie de compilation, mais aussi de features du processeur. La, ça me semble vraiment hasardeux (sans compter que les points comme l'alignement, l'aliasing... ne sont pas suffisament traités).

---

C'est la raison pour laquelle on a proposé N3571

Merci pour ton retour, Emmanuel Deloget.

Ça ma motivé pour mettre le nez dans ces propositions.

Citation:

---

Envoyé par Joel F

C'est la raison pour laquelle on a proposé N3571

---

Qui est une belle proposition, vu qu'elle ne fait pas dire au programmeur "cher compilateur, fait quelque chose que tu ne sais pas faire" si le compilateur ne supporte pas la vectorisation. De plus, en passant par un simd::pack<>, tu peux forcer l'alignement comme tu le souhaite (attention aux vecteurs de simd::pack<> : il faut continuer à garantir l'alignement, même lorsque les données sont dans un conteneur qui n'alloue pas nécessairement des zones de mémoire alignées sur 128 bits ; remarque, une spécialisation partielle de allocator<> devrait pouvoir aider).

Un bémol quand même sur les fonctions mathématiques : que se passe-t-il si le hardware ne gère pas toutes les fonctions proposées ? (je pense notamment au jeu d'instruction NEON). Autre point: pas de swizzling ?

Citation:

---

Envoyé par Emmanuel Deloget

Qui est une belle proposition, vu qu'elle ne fait pas dire au programmeur "cher compilateur, fait quelque chose que tu ne sais pas faire" si le compilateur ne supporte pas la vectorisation. De plus, en passant par un simd::pack<>, tu peux forcer l'alignement comme tu le souhaite (attention aux vecteurs de simd::pack<> : il faut continuer à garantir l'alignement, même lorsque les données sont dans un conteneur qui n'alloue pas nécessairement des zones de mémoire alignées sur 128 bits ; remarque, une spécialisation partielle de allocator<> devrait pouvoir aider).

---

C'est prevu

Citation:

---

Envoyé par Emmanuel Deloget

Un bémol quand même sur les fonctions mathématiques : que se passe-t-il si le hardware ne gère pas toutes les fonctions proposées ? (je pense notamment au jeu d'instruction NEON).

---

on a deja fait ce travail mille fois. Boost.SIMD a genre 400+ fonctions

Citation:

---

Envoyé par Emmanuel Deloget

Autre point: pas de swizzling ?

---

c'est shuffle

Je n'ai pas encore tout lu mais ces derniers jours c'est ma lecture du soir. J'en suis au document sur les executor, sujet qui me touche particulierement. J'espere qu'ils ne vont pas mettre trop de temps a poser les outils pour tout ce qui est parallelisme de taches, parceque pour l'instant c'est pas encore top top sans ITBB et meme avec.

Citation:

---

Envoyé par Joel F

c'est shuffle

---

Un lien ? Une référence ? J'ai déjà cherché parce que j'en avait besoin une fois, et rien trouvé, c'est existant ou ça va arriver (probablement) avec une prochaine maj du langage ?

Sinon pour savoir, a propos de toutes ces discussions, qui peut faire une proposition (tout le monde ?), qui vote ces propositions ?

Citation:

---

Envoyé par Joel F

C'est prevu

---

apres reflexion un vector de pack n'a pas de sens. si tu fait ca c'est plutot un vector de T parcouru via simd::transform

Citation:

---

Envoyé par Joel F

c'est shuffle

---

Arf. J'avais vu shuffle, et je n'avais même pas capté. Désolé :oops:

Citation:

---

Envoyé par Joel F

apres reflexion un vector de pack n'a pas de sens. si tu fait ca c'est plutot un vector de T parcouru via simd::transform

---

La, j'ai un doute. Selon moi (mais je peux me tromper) un vector de pack a un sens - si, par exemple, je veux faire la même multiplication matricielle sur un grand nombre de vecteurs. Dans ce cas,

Code:

---

1 2 3 4 5 6 7

typedef std::simd::pack<float> pack_type; std::vector<pack_type, std::simd::allocator<pack_type>> v; matrix_type mat; // encapsule 4 pack<float>. std::transform(v.begin(), v.end(), v.begin(), [mat](const pack_type& p) -> pack_type { return mat * v; // 4 * operator*(pack,pack) });

---

Je trouve ça un poil plus élégant (et plus naturel à écrire) que d'utiliser simd::transform(). (à ce propos, ça vaudrait peut-être le coup de rajouter à votre proposition

Code:

---

1 2 3 4 5 6

#include <simd> namespace std { template <class T, class N> class allocator<simd::pack<T, N>>; }

---

Ceci dit, ce n'est que mon avis :) Vous avez réfléchi plus longtemps que moi à la question (mais dans le contexte de boost ; dans le contexte de la librairie standard, il y a d'autres interactions intéressantes à prévoir).

Au fait, tu (ou l'un des autres co-auteur) vas y aller à Portland pour défendre votre proposition ?

Citation:

---

Envoyé par Emmanuel Deloget

La, j'ai un doute. Selon moi (mais je peux me tromper) un vector de pack a un sens - si, par exemple, je veux faire la même multiplication matricielle sur un grand nombre de vecteurs. Dans ce cas,

---

A voir, pack c'ets une abstraction de registre SIMD et avoir un vector de registre ca semble awkward.

Citation:

---

Envoyé par Emmanuel Deloget

Ceci dit, ce n'est que mon avis :) Vous avez réfléchi plus longtemps que moi à la question (mais dans le contexte de boost ; dans le contexte de la librairie standard, il y a d'autres interactions intéressantes à prévoir).

---

En pratique on en a jamais eu besoin, donc apres a voir ce que sorte d'autre gens.

Citation:

---

Envoyé par Emmanuel Deloget

Au fait, tu (ou l'un des autres co-auteur) vas y aller à Portland pour défendre votre proposition ?

---

Moi non mais mathias oui.

Citation:

---

Envoyé par Emmanuel Deloget

[*]"std::split(): An algorithm for splitting strings" : moui. Peut-être.

---

Comment ça "moui" :D Moi je serais bien content d'avoir enfin un moyen standard, facile d'utilisation et efficace pour de la tokenisation basique de strings en C++. (C'est quand même plus important que de rajouter de la recherche par Boyer-Moore que personne n'utilisera jamais :langue2:) Perso, j'ai toujours trouvé un peu honteux que l'on est pas d'équivalent à strtok et la honte atteint son sommet en lisant cette question sur stack overflow : What's the most elegant way to split a string in C++? : Là ou dans quasiment tous les les langages splitter une string se fait en une ligne ou deux apparement les solutions "élégantes" en C++ sont des horreurs à base de istream_iterator/stringstream/getline ou alors nécessite boost/plus de vingt lignes de code etc...

Je remarque d'ailleurs que ce papier est lié à un petit paquet d'autres papiers : range(N3513)/string_view(N3609)/split(N3593)/join(N3594) qui passent un peu sous le radar par rapport à la déferlante de feature majeures (parallèlisme et asynchronisme à gogo, lambda générique, concept etc) mais je serais prêt à parierque ces quatres là s'ils sont acceptés auront plus d'impact sur l'écriture du code au jour le jour que tous les autres réunis.

C'est pareil avec le C++11, c'est toujours les lambda/auto/rvalue reference/smart pointer etc qui sont évoqués en premier dans les articles ou les présentations sur les nouveautés du langage alors qu'en pratique AHMA c'est de très loin le foreach (range based for) dont on parle relativement peu qui a un impact le plus important sur l'écriture de code C++.

Citation:

---

Bien évidemment, ce n'est qu'un première réflexion, avec une lecture en diagonale.

---

Merci pour cette première passe c'est vraiment très utile.
Plus qu'à commenter les ~ 60 autres papiers restant maintenant :aie:

Citation:

---

Envoyé par Arzar

C'est pareil avec le C++11, c'est toujours les lambda/auto/rvalue reference/smart pointer etc qui sont évoqués en premier dans les articles ou les présentations sur les nouveautés du langage alors qu'en pratique AHMA c'est de très loin le foreach (range based for) dont on parle relativement peu qui a un impact le plus important sur l'écriture de code C++.

---

Mon experience a ete diffrente jusqu'ici mais peut etre parceque depuis un peu plus d'un an je ne fais quasimment que du nouveau code. C'est la disponibilite des lambda qui a change pas mal la maniere dont j'organise le code.

Pareil, j'ai une préférence pour les algo+lambda que les range for (que j'utilise pratiquement pas)

auto et smart ptr, c'est probablement un tort que cela ne soit pas plus utilisé

la feature la plus utilisée est probablement la move semantic, mais de manière cachée dans la stl

Hum bon, joker, peut être qu'avec une base de code entièrement neuve les lambdas permettent en effet une modification significative dans la manière de coder.

En fait le code C++ typique qui me tombe sous les yeux (ou que j'ai pu voir dans des boulots précédents) ressemblent plutôt à du code de ce genre :

http://llvm.org/svn/llvm-project/cfe.../Sema/Sema.cpp

Et dans cet exemple, sur 1300 lignes je vois à peu près 10/15 boucles qui pourraient être remplacés avantageusement par des foreach, par contre je ne vois pas bien où utiliser des lambdas.

Il parait que la prochaine norme interdira les boucles for et qu'il faudra utiliser uniquement les algos de la STL à la place... :aie:

Citation:

---

Envoyé par gbdivers

Il parait que la prochaine norme interdira les boucles for et qu'il faudra utiliser uniquement les algos de la STL à la place... :aie:

---

Raté, dans la prochaine norme on aura des boucles for encore plus compliquées, voir le papier n3587 dans le mailing pre-bristol : For Loop Exit Strategies :langue2:

Je ne comprend pas le problème du "implicit signature changes" dont parle ce papier. Quelqu'un pourrait m'expliquer en 2 mots?

Citation:

---

Envoyé par Arzar

Raté, dans la prochaine norme on aura des boucles for encore plus compliquées, voir le papier n3587 dans le mailing pre-bristol : For Loop Exit Strategies :langue2:

---

Je pense qu'il faisait allusion à un troll débat que nous avons eu ici même il y a quelques mois :)

Oui je sais, mais je trouvais amusant qu'il y ait justement un papier dans le mailing de ce mois-ci proposant non pas de les bannir :mouarf: mais de les améliorer (bon après pour être franc je serais extrêmement surpris que ce papier soit accepté)

C'est intéressant cette histoire de "Concepts Lite: Constraining Templates with Predicates". Ça m'eût été bien utile en ce moment. Mais ça me dit quelque chose. Ce n'était pas déjà une modification candidate pour le c++11?

Citation:

---

Envoyé par r0d

C'est intéressant cette histoire de "Concepts Lite: Constraining Templates with Predicates". Ça m'eût été bien utile en ce moment. Mais ça me dit quelque chose. Ce n'était pas déjà une modification candidate pour le c++11?

---

C'est une version "light" des Concepts qui sous sa forme C++0x a ete rejete parceque pas encore assez bonne. Ya une variante qu'ils ont propose apres la sortie de C++11 mais qui necessite beaucoup de travail pour verifier qu'elle est une bonne solution. Le probleme c'est que si les Concepts sont acceptes, a priori ca sera pas avant 2017 ce qui est loin. Du coup ils propose une version light, qui ajoute tres peu au C++11 et qui pourrait etre propose en TS ou autre module implementable pour les compilateurs avant ou autour 2014.

Citation:

---

Envoyé par Iradrille

Un lien ? Une référence ? J'ai déjà cherché parce que j'en avait besoin une fois, et rien trouvé, c'est existant ou ça va arriver (probablement) avec une prochaine maj du langage ?

Sinon pour savoir, a propos de toutes ces discussions, qui peut faire une proposition (tout le monde ?), qui vote ces propositions ?

---

j'avais zappé. N3571 est une proposal basé sur boost.simd qu'on developpe chez nous en vue d el'inclusion dans boost.

Citation:

---

Envoyé par Iradrille

Un lien ? Une référence ? J'ai déjà cherché parce que j'en avait besoin une fois, et rien trouvé, c'est existant ou ça va arriver (probablement) avec une prochaine maj du langage ?

Sinon pour savoir, a propos de toutes ces discussions, qui peut faire une proposition (tout le monde ?), qui vote ces propositions ?

---

Chapitres 4.3.3 et 5.4.2 dans N3571