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).
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.
[^] # Re: Erreur de livre et experts C++
Posté par lmg HS (site web personnel) . En réponse à la dépêche C++17 fixe l’ordre d’évaluation des expressions. Évalué à 2.
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).methodavec 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)quemachainesoit unestd::string, unestd::string_view, uneQString, uneCString, uneossimString... ou tout simplement un tableauchar(&)[N], ou encore un pointeur sur chaine 0-terminéechar*. Avec l'écriture point, on perd les deux dernières possibilités.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.
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.
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.