N'oubliez pas les utilisateurs qui vont trouver que l'implémentation n'est jamais assez bien, bibliothèque standard ou pas. Un coup il y a trop d'allocations, ou alors les allocateurs par défaut ne conviennent pas. Une autre fois on considère que l'implémentation gère trop de cas et est trop complexe, d'autres fois elle ne gère pas assez bien le cas principal...
Par exemple j'ai vu des mécontents du fait que la gestion du compteur de std::shared_ptr est thread safe et qu'on paye l'atomic même si le pointeur est restreint à un seul thread. Certains aimeraient aussi avoir la small vector optimization, similaire à small string optimization mais pour std::vector.
D'une manière similaire on a pléthore de bibliothèques pour parser du Json, mais laquelle devrait être dans la bibliothèque standard, nlohmann::json avec sa merveilleuse syntaxe et ses performances moyennes ou bien RapidJSON avec sa syntaxe lourde et ses performances impressionnantes ?
Perso j'ai l'impression que la communauté C++ ne peut pas être satisfaite. Nous voulons des bibliothèques performantes, configurables mais simples à utiliser, avec une syntaxe claire, sans dépendances, génériques mais avec peu de templates et encore moins des macros, mais aussi des temps de compilation courts. Nous voulons un super système de build mais pas CMake parce que sa syntaxe est nulle et pas Meson parce que CMake fait déjà le boulot. Nous voulons aussi un gestionnaire de paquets, mais pas Conan parce que c'est du Python, ni vcpkg parce qu'on ne peut pas spécifier les versions, ni Hunter parce que c'est du CMake. Et au passage on voudrait aussi que les dépendances soient précompilées pour notre compilateur et avec une certaine combinaison de paramètres de compilation.
Bref, on ne peut pas satisfaire la communauté C++.
[^] # Re: Mon avis (professionnel)
Posté par Julien Jorge (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 7.
N'oubliez pas les utilisateurs qui vont trouver que l'implémentation n'est jamais assez bien, bibliothèque standard ou pas. Un coup il y a trop d'allocations, ou alors les allocateurs par défaut ne conviennent pas. Une autre fois on considère que l'implémentation gère trop de cas et est trop complexe, d'autres fois elle ne gère pas assez bien le cas principal...
Par exemple j'ai vu des mécontents du fait que la gestion du compteur de
std::shared_ptrest thread safe et qu'on paye l'atomic même si le pointeur est restreint à un seul thread. Certains aimeraient aussi avoir la small vector optimization, similaire à small string optimization mais pourstd::vector.std::functionn'est pas assez bien et on vante les mérites de The Fastest Possible C++ Delegates, The Impossibly Fast C++ Delegates ou, encore mieux, The Impossibly Fast C++ Delegates, Fixed ; tout en omettant de noter le manque de souplesse de ces implémentations.D'une manière similaire on a pléthore de bibliothèques pour parser du Json, mais laquelle devrait être dans la bibliothèque standard,
nlohmann::jsonavec sa merveilleuse syntaxe et ses performances moyennes ou bien RapidJSON avec sa syntaxe lourde et ses performances impressionnantes ?Perso j'ai l'impression que la communauté C++ ne peut pas être satisfaite. Nous voulons des bibliothèques performantes, configurables mais simples à utiliser, avec une syntaxe claire, sans dépendances, génériques mais avec peu de templates et encore moins des macros, mais aussi des temps de compilation courts. Nous voulons un super système de build mais pas CMake parce que sa syntaxe est nulle et pas Meson parce que CMake fait déjà le boulot. Nous voulons aussi un gestionnaire de paquets, mais pas Conan parce que c'est du Python, ni vcpkg parce qu'on ne peut pas spécifier les versions, ni Hunter parce que c'est du CMake. Et au passage on voudrait aussi que les dépendances soient précompilées pour notre compilateur et avec une certaine combinaison de paramètres de compilation.
Bref, on ne peut pas satisfaire la communauté C++.