C'est pour moi toute la difficulté de la gestion des dépendances. Faut-il lier une bibliothèque externe, la gérer comme un bloc immuable et ainsi profiter de l'expérience des autres ? Faut-il la copier-coller dans le projet pour en faire la base d'un outil interne que l'on peut modifier librement au risque de compliquer ses mises à jour ?
Il y a des outils que l'on prend tels quels, Boost bien sûr, Google Breakpad, Google Test, JsonCPP, entre autres. Ce sont des outils assez gros et nous ne ferions probablement pas mieux en les réécrivant. Néanmoins si nous avions au moins fait une interface à JsonCPP nous aurions sans doute pu simplement changer pour rapidjson ou autre le jour où nous l'avions envisagé. Celui là a par exemple été à la fois un accélérateur et une gêne.
À côté de ça il y a des outils que l'on aurait bien voulu prendre tels quels, Cocos2d-x, MoFileReader, Spine, Soomla, mais le besoin a appelé des modifs et les mises à jour sont de plus en plus difficiles.
Alors est-ce qu'on aurait vraiment gagné du temps ou de la performance en piochant dans libc++ ? Pour l'inclusion d'optional par exemple, on part sur Boost, la compilation est lente (300 ms. sur mon pc pour un g++ -c test.cpp où test.cpp ne contient que #include <boost/optional.hpp>). Je teste avec la STL en c++17 : 250 ms. bof. Alors nous l'implémentons à notre sauce, ça coûte quelles que heures de dev, je teste la même compilation : 30 ms. Et quand je teste en essayant de copier la version de libc++ ça ne compile même pas car il manque des dépendances :/
Dès fois c'est plus simple de prendre un outil existant tel quel, d'autres fois c'est la plaie. Parfois, comme avec libc++ ici, il faut passer du temps à gérer la compilation ou à extraire la seule partie qui nous intéresse. Pour moi le problème est loin d'être simple. Et encore là je parle de compilation desktop mais en pratique nous faisons des builds iOS, Android, OSX et Linux.
En ce moment je regarde d'ailleurs la gestion de dépendance avec Conan et je dois me faire violence pour plonger dedans plutôt que de bêtement compiler des .a et les archiver sur un bucket S3. Il me semble que tu avais regardé ces outils de gestion de dépendance en c++, en utilises-tu ?
[^] # Re: NIH ?
Posté par Julien Jorge (site web personnel) . En réponse au journal Publication de bibliothèques c++ sous licence libre. Évalué à 5.
C'est pour moi toute la difficulté de la gestion des dépendances. Faut-il lier une bibliothèque externe, la gérer comme un bloc immuable et ainsi profiter de l'expérience des autres ? Faut-il la copier-coller dans le projet pour en faire la base d'un outil interne que l'on peut modifier librement au risque de compliquer ses mises à jour ?
Il y a des outils que l'on prend tels quels, Boost bien sûr, Google Breakpad, Google Test, JsonCPP, entre autres. Ce sont des outils assez gros et nous ne ferions probablement pas mieux en les réécrivant. Néanmoins si nous avions au moins fait une interface à JsonCPP nous aurions sans doute pu simplement changer pour rapidjson ou autre le jour où nous l'avions envisagé. Celui là a par exemple été à la fois un accélérateur et une gêne.
À côté de ça il y a des outils que l'on aurait bien voulu prendre tels quels, Cocos2d-x, MoFileReader, Spine, Soomla, mais le besoin a appelé des modifs et les mises à jour sont de plus en plus difficiles.
Alors est-ce qu'on aurait vraiment gagné du temps ou de la performance en piochant dans libc++ ? Pour l'inclusion d'optional par exemple, on part sur Boost, la compilation est lente (300 ms. sur mon pc pour un
g++ -c test.cppoùtest.cppne contient que#include <boost/optional.hpp>). Je teste avec la STL en c++17 : 250 ms. bof. Alors nous l'implémentons à notre sauce, ça coûte quelles que heures de dev, je teste la même compilation : 30 ms. Et quand je teste en essayant de copier la version de libc++ ça ne compile même pas car il manque des dépendances :/Dès fois c'est plus simple de prendre un outil existant tel quel, d'autres fois c'est la plaie. Parfois, comme avec libc++ ici, il faut passer du temps à gérer la compilation ou à extraire la seule partie qui nous intéresse. Pour moi le problème est loin d'être simple. Et encore là je parle de compilation desktop mais en pratique nous faisons des builds iOS, Android, OSX et Linux.
En ce moment je regarde d'ailleurs la gestion de dépendance avec Conan et je dois me faire violence pour plonger dedans plutôt que de bêtement compiler des .a et les archiver sur un bucket S3. Il me semble que tu avais regardé ces outils de gestion de dépendance en c++, en utilises-tu ?