C'est marrant, j'ai exactement l'avis opposé. Je trouve beaucoup plus intuitif de faire obj.methode() pour une action que func(obj).
Mon commentaire, n'était pas pour ajouter des méthodes à std::string, mais pour dire que l'interface initiale est pourrie, car trop basée, comme pour les premières classes de la STL, sur des idées 1980 (code ASCII 8bits, tout le monde parle anglais, etc...), et pas assez sur l'utilisation de l'objet lui-même. Dans la réalité des codes utilisant du std::string que j'ai lu (et j'en lis beaucoup), 99.9% du temps, les indices sont inutiles, plein de bugs, etc...
L'exemple le plus flagrant, c'est lorsque je dois faire l'i18n d'une appli C++. Le développeur ne sait pas (ou a "oublié") qu'il travaillait avec de l'UTF-8, et estime, à tort que l'index d'un caractère est égal à sa position en mémoire. Avec une interface sans index à gérer, il n'y a aucun soucis. Avec std::string, c'est l'horreur. Avec une classe utilisant le pattern "from_first", "upto_last", etc, ça roule tout seul.
Traduire le code des iostreams c'est aussi une autre hérésie qui n'aurait jamais dû survivre à plus d'un standard. Le grand classique, que j'ai vu à de nombreuses reprises, c'est "cout << "There is " << animal_count << " pet" << animal_count ? 's' : '0円' << " in the store."<< endl;
En général, là, le code est à réécrire (grand moment de solitude). Franchement, séparer la présentation des données, même le C le faisait en 89 avec printf et gettext, le C++ n'y est toujours pas (il y a boost::format mais bon... boost quoi...).
De plus, l'interface des string aurait due être séparée en "méthodes" non modifiantes, "méthodes modifiantes", quitte à faire une classe "readonly_string" qui permette les recherches, les modifications de taille (ou du pointeur de début de chaîne) mais pas du contenu de la chaîne (bref: tout ce qui est requis pour parser du texte), et une classe "writeable_string" pour le reste, en ayant un héritage multiple des deux interfaces dans ce qui s'appelle la classe string. Du coup, la problématique du COW disparaît automatiquement suivant que l'on veuille en payer le prix ou non (pour le parsing, par exemple, pas de COW pour du RO).
[^] # Re: Erreur de livre et experts C++
Posté par xryl669 . En réponse à la dépêche C++17 fixe l’ordre d’évaluation des expressions. Évalué à 4.
C'est marrant, j'ai exactement l'avis opposé. Je trouve beaucoup plus intuitif de faire obj.methode() pour une action que func(obj).
Mon commentaire, n'était pas pour ajouter des méthodes à std::string, mais pour dire que l'interface initiale est pourrie, car trop basée, comme pour les premières classes de la STL, sur des idées 1980 (code ASCII 8bits, tout le monde parle anglais, etc...), et pas assez sur l'utilisation de l'objet lui-même. Dans la réalité des codes utilisant du std::string que j'ai lu (et j'en lis beaucoup), 99.9% du temps, les indices sont inutiles, plein de bugs, etc...
L'exemple le plus flagrant, c'est lorsque je dois faire l'i18n d'une appli C++. Le développeur ne sait pas (ou a "oublié") qu'il travaillait avec de l'UTF-8, et estime, à tort que l'index d'un caractère est égal à sa position en mémoire. Avec une interface sans index à gérer, il n'y a aucun soucis. Avec std::string, c'est l'horreur. Avec une classe utilisant le pattern "from_first", "upto_last", etc, ça roule tout seul.
Traduire le code des iostreams c'est aussi une autre hérésie qui n'aurait jamais dû survivre à plus d'un standard. Le grand classique, que j'ai vu à de nombreuses reprises, c'est
"cout << "There is " << animal_count << " pet" << animal_count ? 's' : '0円' << " in the store."<< endl;En général, là, le code est à réécrire (grand moment de solitude). Franchement, séparer la présentation des données, même le C le faisait en 89 avec printf et gettext, le C++ n'y est toujours pas (il y a boost::format mais bon... boost quoi...).
De plus, l'interface des string aurait due être séparée en "méthodes" non modifiantes, "méthodes modifiantes", quitte à faire une classe "readonly_string" qui permette les recherches, les modifications de taille (ou du pointeur de début de chaîne) mais pas du contenu de la chaîne (bref: tout ce qui est requis pour parser du texte), et une classe "writeable_string" pour le reste, en ayant un héritage multiple des deux interfaces dans ce qui s'appelle la classe string. Du coup, la problématique du COW disparaît automatiquement suivant que l'on veuille en payer le prix ou non (pour le parsing, par exemple, pas de COW pour du RO).