lmg HS a écrit 174 commentaires

NB: il proposait d'utiliser optional<> pour faire plus que la sémantique portée par son nom : il proposait de l'utiliser comme le std::expected<> en cours d'élaboration. Cf mes commentaires dans cette autre dépêche.

L'intégration des VLA n'est-il pas toujours en discussion ?

On a failli, et puis finalement non. Je n'ai pas suivi ce sujet -> ne pas me demander pourquoi.

Le C++ est clairement un langage que plus on le connait, plus on sait à quel point on ne sait pas grand chose. Mais ce n'est pas très grave. Typiquement, ce genre d'optimisation, ne nous change pas vraiment la vie tant que l'on n'est pas à vouloir optimiser très précisément ce qu'il se passe.

De plus, et c'est particulièrement vrai depuis le C++11, toutes les choses dans la norme ne sont pas directement pour nous, mais pour des concepteurs de bibliothèques qui pourront nous peaufiner des bibliothèques aux petits oignons qu'il ne nous restera plus qu'à utiliser.

Tous les utilisateurs de Python n'ont pas forcément conscience des dictionnaires qui sont omniprésents et qui expliquent tout ce qu'il est possible de faire avec le langage, en bien ou en mal. Et pourtant, ils n'ont aucun mal à s'en servir. Ici, ce n'est guère différent.

Je viens d'introduire une note au sujet de l'aliasing, mais c'est vrai, sans le code.

Sinon, le problème de la portabilité ne se pose AMA que quand on a des constructeurs avec effets de bords et que ces effets de bords sont importants ou lorsque l'on compare par rapport à un mode débug.

Sinon, le RVO et le NRVO je les avais avec Sun CC 5 (?) il y a plus de 10 ans. Ca serait effectivement malheureux que les compilateurs d'aujourd'hui ne sachent pas faire éluder de façon systématique les cas simples.

C'est Alexandrescu, je crois, qui avait pondu un Iterators must go. C'était un des premiers articles de qualité pour pousser vers les remplacement des paires d'itérateurs par des plages (ranges en VO). Entre temps, il est parti vers le D, et je me demande si justement il n'avait pas participé aux ranges en D.

Bref, la STL v2 est dans cette mouvance. Et sur ce point, nous sommes d'accord, les algos de la STL v1 ne sont pas des plus ergonomiques. Ils ont de la souplesse, mais ils l'exigent de nous également.

C++20 le prochain je pense sinon. Et effectivement, il semblerait plutôt que l'on lorgne du côté des pipe UNIX. Sauf que … au lieu de se contenter d'une monde purement fonctionnel (de variables non modifiables), on traine le boulet OO des états qui sont altérés. D'où le |=. Dans les autres contraintes, il y a les générateurs à la Python. range::ints() et iota() peuvent ainsi générer un nombre (pseudo) infini d'entiers qui seront générés à la volée.

J'ai tendance à penser que cette limitation n'est pas propre aux différentes implémentations de la POO que tu cites, mais est inhérente au paradigme lui-même : la POO, qui met en avant la notion d'abstraction, c'est de l'abstraction vue par un enfant de quinze ans et à un moment, ça coince.

J'ai aussi tendance à avoir cet avis, mais dans le doute (car je suis loin de connaitre les langage OO qui flirtent de très près avec le monde fonctionnel) j'ai préféré spécifier un contexte.

Utiliser la SL a tout à voir avec la programmation générique. Avant de disposer d'un std::vector<>, il faut l'écrire, et après libre à l'utilisateur de s'en servir. Convergeons vers ton exemple (hors STL mais dans la SL) il y a std::basic_string<> ou même std::basic_ostream<>. Très peu ont conscience que ces trucs existent et pourtant ils s'en servent au travers des typedefs std::string, std::ostream, ou carrément via la variable globale std::cout.

Ces types sont génériques. Si les chaines ne piochent dans le paradigme OO que l'abstraction et l'encapsulation, les flux sont quant à eux plein d'héritage, multiple de surcroit, de points de variations dynamiques (ou comment filtrer à la volée un flux ou l'altérer pour justifier un texte p.ex.), de design pattern Stratégie, et je peux en oublier. Et ? Ils sont totalement génériques sur le type de caractères, et sur les descriptifs des caractères.

Nous sommes du côté d'une bibliothèque et pas d'un code métier. Et c'est probablement ça qui fait toute la différence. Côté métier offrir de la généricité est moins souvent pertinent. De fait une classe EtatCivil n'a pas grand intérêt à être générique. Côté bibliothèque j'ai pu travailler avec ITK et OTB, là on a des types images dans une hiérarchie avec pourtant un paramètre template pour le type de pixel. On a aussi des hiérarchies encore plus touffues pour dire qu'un truc assimilable à une image peut être une image, un fichier ou une transformation qui va servir à calculer une nouvelle image. Pour le coup ITK utilise des hiérarchies là où la STL (+ std::string) est 100% orientée concepts.

Concernant sort, là tu bloques sur l'écriture OO mainstream on dirait. Parenthèse OO: Personnellement, je constate ici l'échec de Java qui comme le C++ a des types primitifs, mais qui a introduit un Top Type (type dont tout objet dérive). Résultat le code de divers algorithmes comme sort est dupliqué entre les tableaux primitifs et les collections à accès direct. Python n'a pas ce problème. Il y a un top type chez lui, mais pas de type primitif.

Côté écriture de sort, la STL v2 est en cours de préparation. Le C++ assume totalement que la généricité est plus adaptée que des hiérarchies compliquées pour des algorithmes. L'écriture qui est sympa c'est sort(v) pourquoi est-ce que cela devrait être v.sort()? Avec CLOS, la syntaxe d'appel est (func x y z). Ce qui rend la gestion du dispatch multiple tout ce qu'il y a de plus naturel. Une petite discussion à ce sujet dans un article que j'avais bien aimé (le lien pointe directement sur le paragraphe qui discute s'il faut écrire kick the dog ou dog the kick).

Pour en revenir à la STL v2, en plus de l'écriture action::unique(action::sort(vi));, elle va supporter l'écriture vi |= action::sort | action::unique; qui marcheront aussi sur des tableaux natifs ou sur n'importe quel conteneur à accès direct (seulement? je n'ai pas vérifié) qui expose begin() et end() en libre ou en membre.

Pour la complexité de la STL, je dirai que pour un bonne part c'est une question d'habitude. Pour avoir lu et écouté Stepanov, ce à quoi il a abouti est naturel. Comme en maths, il voit que chaque algo a des prérequis pour être appliqué, à partir de là, hormis les template <typename NomdeConcept1, ... en début de signature, le reste est franchement clair. Après pour le code des implémentations de la SL, il y a la quasi obligation de tout préfixer avec des tirets-bas et la volonté d'auto-adaptativité à la nature des choses manipulées histoire d'optimiser (nous sommes en C++ après tout), ce qui ne rend pas la lecture toujours triviale. Plus des hacks pour éviter de produire des messages d'erreurs trop inintelligibles, plus de la programmation par contrat. Mais est-ce que cela nous concerne vraiment ?

Je rajouterai aussi pour avoir essayé de jouer à ça dans ma jeunesse que le paradigme OO (tel qu'implémenté en Pascal/Delphi, C++ et Java) est totalement incapable de modéliser correctement les notions de groupes, anneaux et cie quant on commence à vouloir introduire du dispatch multiple dans des fonctions.

Les projets réels les utilisent tout le temps.
- Je veux un tableau dans une classe concrète? std::vector<>. C'est générique et je m'en sers.
- Je veux un truc qui va collecter automatiquement la mémoire ou n'importe quoi d'autre ? std::unique_ptr<>.
- Je veux trier un tableau ? std::sort()
- Je veux des images avec des types de pixel générique ? Ca marche aussi.

On ne va pas faire 100% dans un style et 100% dans un autre. On va prendre le style qui va bien pour un besoin donné. De la même façon que l'on ne va pas dériver pour le plaisir. On compose bien souvent à la place car cela offre plus de souplesse en ouvrant la porte au pattern Stratégie.

PS: Dans le monde des typeurs de canards cela que l'on nomme juste "polymorphisme" désigne le "polymorphisme paramétrique" qui en C++ correspond aux templates, et qui est statique (en C++).

s/peu réception/peu réceptif—il y a en d'autres, mais là ça ne veut vraiment plus rien dire…

OK, je pense voir ce que tu veux dire.

Tu es sur l'interface d'utilisation. J'étais sur POO pour l'interface et templates (qui ne doivent pas fuir au niveau de l'interface) pour l'implémentation—ce qui n'a rien de bancal. Effectivement, le C++ n'offre pas un polymorphisme paramétrique dynamique. En C++, le duck typing c'est 100% à la compilation.

Il y a feintes pour essayer de combiner tout ce beau monde. Cf les articles qui parlent de type erasure en C++—pas sûr que le même sens soit donné dans d'autres communautés.

Bref, il y a des cas de combinaison possibles sur une même famille de types. Et ça marche très bien. Le truc, c'est que dans ce cas, je ne veux pas d'un at() qui renvoie un template—enfin je ne veux jamais de at() étant peu réception à la programmation défensive, mais c'est une autre histoire, je sais ne pas pouvoir vouloir d'un T ITruc::operator[]() non plus—oui, de connaitre la limitation, ça oriente fortement ce que je m'autorise à vouloir faire.

NB: l'équivalent template de l'interface, c'est le concept.

Pour les raisons, je pense qu'il faille aller chercher dans le technique. En C++, les template s'appliquent sur des scalaires comme des objets, et c'est assez contraignant. Je ne sais pas comment font C# et D sur cet aspect.

Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires.

Et du coup, il faut combien de décennies d'apprentissage avant de savoir choisir le bon paradigme?

Combien de décennies faut-il pour savoir correctement concevoir? Je ne parle même pas de programmer, mais d'assimiler l'OO avec ses bonnes pratiques, le génie logiciel, la gestion des ressources, etc. Tout demande un investissement dans nos métiers—je sais que ce n'est pas ce que nos employeurs voudraient entendre.

Et pour savoir quoi choisir, la question, mes collègues savent toujours y répondre: est-ce un choix qui se fait à la compilation ? A l'exécution ? Au lancement ?

Après, j’admets volontiers que les choses deviennent compliquées quand on veut le beurre et l'argent du beurre. Exemple typique : un calcul sera appliqué sur des pixels d'images du spatial (en 10000x10000), mais la nature du calcul on ne la connait pas avant que l'utilisateur ne lance l'application. Là on veut un point de variation dynamique, et éviter de payer pour ce choix à l'exécution.

Je pense que personne ne considère qu'utiliser les conteneurs de la STL revient à faire de la programmation générique.

En termes de paradigmes, certains distinguent la programmation générique où l'on va utiliser, voire écrire des types génériques (comme on faisait en Ada sans que cela ne choque personne), et la métaprogrammation template où l'on va commencer à adapter automatiquement l'algorithme générique choisi en fonction des types que l'on manipule (p.ex. un tri sur une collection qui offre un accès direct et celui sur une collection qui n'offre qu'un accès séquentiel ne sera pas le même ; std::copy sur des POD pourra utiliser memcpy, etc).

Les trucs les plus avancés que j'ai fait dans du code métier, c'est définir des listes de types décrivant des informations pouvant être extraites d'une trame binaire (ordre, nb bits dans la trame, type C++ associé après décodage). J'ai fait ça par métaprog. D'autres décrivent les trames en XML et font des parseurs compliqués, ou des générateurs de code. Dans tous les cas, un investissement est requis pour la technique employée.

Pour le fenouil braisé, on a des mécanismes similaires : l'envie de creuser, le temps, l’honnêteté d'admettre que c'est adapté (ou non!!) à une situation. Il y a beaucoup de critères. L'essentiel de ces critères est humains. Je renvoie à la première partie de la dernière présentation de Dan Saks au CppCon2016. Çà fait bien 20ans (plus?) qu'il essaie de vendre le typage supérieur à 0 surcoût du C++ avec template à la communauté C embarqué. Dans la première partie de la vidéo, il revient sur ce qui s'est passé et les raisons (humaines) de son échec.

Si ceux qui connaissent le C++ sont convaincus que la généricité peut s'importer facilement, voire plus facilement qu'un conception OO de qualité (combien ont compris SOLID et en particulier le LSP, et ce qu'est véritablement l'encapsulation? Trop peu.), pourtant ça bloque.

Tu me dis que ce n'est pas parce que ça (te) fait peur. Pourquoi alors ?

PS: Truc<T> peut tout à fait hériter de ITruc ou de TrucImpl. C'est même assez classique quand on veut combiner une variabilité dynamique avec une statique.

Le SFINAE est un outil qui sert à détecter des informations non triviales ou des possibilités par essai et erreur. Sauf que les erreurs sont ignorées et à la place on se débrouille pour récupérer un truc que l'on va assimiler à faux. Ce booléen on s'en sert ensuite ailleurs pour choisir quelle spécialisation nous intéresse.

Exemple à la C++98

template <typename T>
struct has_typedef_montype
{
    using yes = char[1];
    using no  = char[2];

    // Signatures qui renvoient des choses différentes
    // - Version qui prend ce que l'on cherche
    template <typename C> static yes& test(typename C::montype*);
    // - Version qui prend n'importe qui
    template <typename C> static no & test(...);
    // NB, on n'a pas besoin de définition, mais de renvoyer une réf.

    // Ici le compilo tente de résoudre. 
    // Si T permet d'extraire un type `montype*`, alors on renvoie `yes` qui a une taille de 1
    // Sinon, on défaulte sur la version variadique qui renvoie un `no` de taille 2
    // Ce qui permet de construire le booléen `value` grâce à sizeof qui est toujours résolu à la compilation
    static const bool value = sizeof(test<T>(NULL))==sizeof(yes);
};

struct U { using montype = int; };

int main ()
{
    std::cout << std::boolalpha; // affiche true ou false
    std::cout << has_typedef_montype<int>::value << "\n";
    std::cout << has_typedef_montype<U>::value << "\n";
}

Façon C++14 (voire 17), on a de nouveaux outils:

#if 0
// C++17
// Requiert gcc 5.0
template <typename...T> using void_t = void;
#else
// Pour gcc v < 5.0
// Until CWG 1558 (a C++14 defect), unused parameters in alias templates
// were not guaranteed to ensure SFINAE and could be ignored, so earlier
// compilers require a more complex definition of void_t, such as
template<typename... Ts> struct make_void { typedef void type;};
template<typename... Ts> using void_t = typename make_void<Ts...>::type;
#endif

// Cas par défaut
template <typename T, typename = void>
struct has_typedef_montype
: std::false_type
{};

// Cas où l'on arrive à trouve le typedef qui nous intéresse
template <typename T>
struct has_typedef_montype<T, void_t<typename T::montype>>
: std::true_type
{};

Injecter -Iunchemin dans la ligne de compilation c'est une chose, injecter en plus un -Dtrucquisededuitdufichiervisibledans$INCLUDE, ce n'est pas DRY: on répète des informations que l'outil aurait pu déduire pour nous.

De plus, quid des projets sur gcc.goldbot. Comment savoir à l'avance si on va disposer d'une fonctionnalité ou d'autre autre?

Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires. Si je dois gérer mes observateurs à la main, je vais utiliser les classes génériques standards. Ne pas le faire serait totalement idiot de ma part.

Pareil, pour gérer la mémoire, par défaut je vais utiliser des unique_ptr<> qui sont génériques. Et je les mettrai dans des objets.

Je comprends que devoir écrire ce genre de classe from scratch fasse peur à quelqu'un qui n'est pas habitué à la lourdeur de la syntaxe et à qui l'école n'a appris qu'un bout de l'OO (pour factoriser des données de bases de données et non pas pour factoriser des comportements) et du procédural. Mais pour la majorité d'entre nous, on n'a rien de tel à écrire. Juste à utiliser.

Reste que ce ne sont pas des paradigmes opposés.

Je dirai aussi, que le mélange est tout sauf récent. Cf la Thèse de Jim O Coplien qu'il a ultérieurement édité en livre: Multiparadigm Design in C++—cf la FAQ de dvpz pour les liens. Un des aspects les plus intéressants, c'est toute la partie sur la dualité commonalities et variability points. C'est le B à ba. On a des zones de code communes, et dedans, il y a des points où des détails vont varier. Et ça on sait le faire depuis longtemps: socket win32 ou socket POSIX ? Tableau d'entiers ou tableau de doubles ? Affichage de carrés, cercles, polygones ou autre figure géométrique ?

Toute la question est la dynamicité derrière les points de variations—et leur potentielle capacité à évoluer sans requérir de modification. Est-ce quelque chose que l'on sait déterminer dans le code source ? En fonction de la plateforme de build ? Est-ce lié à des plugins (choix du .so à charger)? Est-ce totalement dynamique ? Et bien en fonction de ça, ou va jouer avec des #if, on va compiler un .c ou un autre, on va avoir des instances d'un type ou d'un autre, ou on va choisir le paramètre template d'un type générique.

Bref. C'est juste un autre levier qui offre plus de finesse. Et dans un même projet, il peut être intéressant de disposer de plusieurs façons pour procéder.

Sauf si le nouveau truc est un mot clé.
Imagine une bibliothèque pré C++11 avec un my::constexpr. En C++11, ça ne peut plus compiler.

s/tour/retour

Si cette évolution va simplifier l'écriture de fonctions récursives telles que les templates variadiques comme montré en exemple dans la dépêche, je redoute pour ma part un tour arrière sur le principe ouvert (aux évolutions) fermé (aux modifications).

Souvenez-vous, c'est le principe qui dit que dans un monde OO, les if c'est mal, et que les fonctions virtuelles c'est mieux. L'idée est que quand nous identifions des points de variations, plutôt que de modifier le code pour ajouter des nouveaux cas à coups de if ou de switch, à la place, on prévoit un point de variation ouvert qui pourra accepter de façon plug-and-play des nouveaux cas non encore identifiés/définis.

Si l'OO nous offrait un OCP dynamique, jusqu'à présent on employait des traits ou le SFINAE (c'est pas vraiment des traits le SFINAE) en métaprogrammation template. Pour ceux qui connaissent le Prolog (voire XSLT), on retrouve quelques part le principe de résolution par unification.

C'est sûr qu'un if c'est plus simple et plus accessible. Mais c'est beaucoup moins évolutif.

Parenthèse: A.Stepanov se défend que la STL historique ait été conçue OO. Il y a diverses vidéos sur le sujet.

Dans le cas de v.begin() il sous-entend dans son Notes on Programming que pour passer le véto de l'intelligentzia OO qui n'avait pas encore migré vers d'autres langages à l'époque (le subjectif dans le phrasé est mien), il avait dû concéder à faire de size & cie des fonctions membres et non des fonctions libres. Depuis le C++11 on corrige le tir. Il faut attendre C++17 pour avoir std::size()—même s'il est facile à écrire dès le C++11: c'est un oubli.

A noter aussi les propositions autour du Uniform Call Syntax par Stroustrup et d'autres qui n'ont pas été retenues pour le C++17—j'avais donné le lien dans les commentaires d'une précédente dépêche vendredi.

Une question facile :)

En C++, quand il s'agit d'ajouter quelque chose, ils cherchent avant toute chose à n'ajouter aucun nouveau mot clé. L'objectif est de n'introduire aucune régression sur des vieux codes qui compilaient. Ce qui fait que les évolutions se font en priorité dans la bibliothèque standard, puis par réutilisation/dépréciation de mots clés (cf auto).

Avec static_if, il suffit d'une bibliothèque tierce (et je crois bien qu'il en existe justement) qui définit quelque chose avec ce nom, et cela plante définitivement la bibliothèque et tous les codes qui s'en servent.

Pour moi ça se fait en amont dans la chaine de compilation où l'on va forcer quelle source d'une bibliothèque on veut utiliser. __has_include ne me parait pas du tout adapté. Les inline namespace à la limite, mais faut-il encore que la bibliothèque les utilise, et ça ce n'est pas gagné.

Sur des pet projects mono-fichier et sans Makefile, cela permet d'inclure et utiliser simplement std::string_view qui sera dans expérimental ou pas p.ex. C'est sûr que ce n'est pas terrible, mais c'est un moyen de s'en sortir uniquement avec le préprocesseur.

C'est marrant, j'ai exactement l'avis opposé. Je trouve beaucoup plus intuitif de faire obj.methode() pour une action que func(obj).

Je suis de plus en plus de l'avis que ce n'est que du sucre syntaxique. Sucre qui de par sa forme bride le polymorphisme sur un seul argument. Dans un monde où l'on aurait des multimethods (Stroustrup et d'autres y travaillent, pour après le C++17 donc), çà donnerait (o1,o2).method avec la syntaxe point, mais d'autres langages ont choisi [message o1 o2] (ou des trucs approchants que je peux retrouver).

Bref, je regrette un peu que l'Unified Call syntax n'ai pas été retenue pour le C++17: https://isocpp.org/blog/2016/02/a-bit-of-background-for-the-unified-call-proposal

Et quid des types natifs? Dans une fonction générique, on pourrait écrire juste trim(machaine) que machaine soit une std::string, une std::string_view, une QString, une CString, une ossimString… ou tout simplement un tableau char(&)[N], ou encore un pointeur sur chaine 0-terminée char*. Avec l'écriture point, on perd les deux dernières possibilités.

[UTF-8]

Entièrement d'accord qu'il y a plein de soucis, même avec boost.locale (surcouche C++ à ICU), cela reste assez peu intuitif à manipuler.

chaines constantes

Ce que tu décris ressemble à std::(experimental::)string_view. C'est justement la raison pour laquelle je suis persuadé que l'extension d'interface par l'extérieur (on retrouve un des items de (More?) Exception C++ de Sutters—dispo sur http://gotw.ca/gotw aussi) est préférable.

Sur les Cpp Core Guideline, on retrouve les mêmes principes avec les span. Et on voit vite que l'on n'a pas besoin d'héritage, que c'est simple, que cela ne nécessite pas d'écrire des fonctions templates, et que c'est aussi efficace que le couple pointeur+taille du C.

Sinon, ce sujet me rappelle la profusion de classes pour les chaines de caractères dans Adobe.ASL. Là, on a toujours un outil ad'hoc, mais c'est plus complexe pour le pékin moyen que nous sommes qui préfère un seul type pour les unir toute, à la QString.

D'accord aussi que produire uniquement des nouvelles chaines (à la mode fonctionnelle: i.e. pas d'altération d'état) aurait pu être pal mal du tout.

[flux]

Pour les flux, oui, c'est une catastrophe pour l'i18n. Sur le sujet, je teste spdlog et la bibliothèque de formattage sous-jacente en ce moment.

s/des macro/&s/
s/pertienent/pertinent/

Pas besoin de payer pour du COW. Le déplacement marcherait très bien si on travaille sur une chaine sans changer sa taille.

Maintenant, dans "classe string, qui ne propose qu'un nombre limité de méthodes", je lis : "rajoutons des fonctions membres à std::string". Pitié non il y en a déjà bien assez dedans, et pas assez dehors.

Résultat avec l'arrivée des string_view on va se payer une surcharge de trucs déjà écrits, ou l'impossibilité d'utiliser ce boost de performance et d'API unifiée. C'est bien idiot. Je vois régulièrement des projets qui n'ont rien trouvé de mieux à faire que de créer leur propre classe de chaine juste pour rajouter des fonctions membres dedans au lieu de les fournir en libre. Résultat ils écrivent des choses dont ne on pourra pas profiter sur les string_view—ou des équivalentes que l'on pourrait vouloir écrire.

En effet, il n'y a en général guère que dans les guides qualité que l'on peut trouver des références à ces problèmes. Et encore, en général, on se contente du f[i] = i++;.