Globalement, je suis d'accord avec tout ce que tu dis ici, et je suis souvent confronté à ce même problème. J'ai parfois fait des choix sur lesquels je suis revenu ensuite : par exemple, l'UI en mode immédiat, au départ j'ai utilisé un truc simple que j'avais pioché dans un projet quasi-mort mais qui marchait, mais il manquait des fonctionnalités et au final, ça me semblait être une tâche trop ardue d'implémenter ça correctement et rapidement. Au final, j'ai intégré Nuklear qui avait bien plus de fonctionnalités et qui correspondait mieux à ce que je voulais. Mais la question se pose à chaque fois. Je me suis aussi retrouvé à devoir implémenter des petits trucs qui vont venir dans la bibliothèque standard, comme std::string_view.
De toute façon, si je grossis le trait, j'ai fait une implémentation de SFML en prenant SDL comme base, mais j'ai repris beaucoup de code de SFML. Ce qui veut dire qu'il faut suivre les évolutions de SFML (et/ou les corrections de bugs) tout en ajoutant ce dont j'ai besoin. Et je ne parle même pas des morceaux de SFML que j'ai modifiés à ma sauce parce que je trouvais l'implémentation originale moyenne.
Pour répondre à ta question sur la gestion des dépendances, j'essaie d'en avoir le moins possible. Mais ce n'est pas toujours gagné. J'ai deux sortes de dépendances. Premièrement, des dépendances que j'importe directement (via git submodule). Ça concerne en particulier des bibliothèques qui ne sont que des en-têtes et qu'il est plus facile d'utiliser de cette manière (on peut planquer l'implémentation dans un fichier source sans la mettre dans une interface). J'ai stb et Nuklear qui sont comme ça. Ensuite, j'ai des parsers de formats particuliers que je préfère intégrer directement de cette manière plutôt que de passer par une dépendance affichée, je cherche alors des bibliothèques simples (un seul fichier source). J'ai TinyXML et RapidJson dans cette catégorie. Et j'envisage sérieusement de supprimer ces deux dépendances bientôt et de ne passer que par un seul format d'entrée (j'en parlerai peut-être dans un journal bientôt). Et enfin, j'ai GameControllerDB qui contient des données uniquement et Google Test où c'est la manière recommandée de procéder.
Deuxièmement, j'ai des dépendances externes affichées. Là, j'essaie d'en avoir le minimum. J'ai SDL2, Freetype, Boost (seulement certaines parties) et récemment j'ai ajouté Zlib. Pour celles là, j'utilise mon gestionnaire de paquet préféré quand je suis sur Linux et j'utilise l'excellent vcpkg quand je suis sur Windows (j'inclus les plateformes de CI dans ces descriptions). Et ça marche plutôt bien. Je trouve vcpkg très bien foutu, en une seule ligne, on a tout ce qu'il faut prêt à l'emploi. On a une impression d'être à la maison (Linux) tellement c'est simple. En revanche, je déteste Conan cordialement. Je trouve le concept fumeux de base.
[^] # Re: NIH ?
Posté par rewind (Mastodon) . En réponse au journal Publication de bibliothèques c++ sous licence libre. Évalué à 2.
Globalement, je suis d'accord avec tout ce que tu dis ici, et je suis souvent confronté à ce même problème. J'ai parfois fait des choix sur lesquels je suis revenu ensuite : par exemple, l'UI en mode immédiat, au départ j'ai utilisé un truc simple que j'avais pioché dans un projet quasi-mort mais qui marchait, mais il manquait des fonctionnalités et au final, ça me semblait être une tâche trop ardue d'implémenter ça correctement et rapidement. Au final, j'ai intégré Nuklear qui avait bien plus de fonctionnalités et qui correspondait mieux à ce que je voulais. Mais la question se pose à chaque fois. Je me suis aussi retrouvé à devoir implémenter des petits trucs qui vont venir dans la bibliothèque standard, comme
std::string_view.De toute façon, si je grossis le trait, j'ai fait une implémentation de SFML en prenant SDL comme base, mais j'ai repris beaucoup de code de SFML. Ce qui veut dire qu'il faut suivre les évolutions de SFML (et/ou les corrections de bugs) tout en ajoutant ce dont j'ai besoin. Et je ne parle même pas des morceaux de SFML que j'ai modifiés à ma sauce parce que je trouvais l'implémentation originale moyenne.
Pour répondre à ta question sur la gestion des dépendances, j'essaie d'en avoir le moins possible. Mais ce n'est pas toujours gagné. J'ai deux sortes de dépendances. Premièrement, des dépendances que j'importe directement (via git submodule). Ça concerne en particulier des bibliothèques qui ne sont que des en-têtes et qu'il est plus facile d'utiliser de cette manière (on peut planquer l'implémentation dans un fichier source sans la mettre dans une interface). J'ai stb et Nuklear qui sont comme ça. Ensuite, j'ai des parsers de formats particuliers que je préfère intégrer directement de cette manière plutôt que de passer par une dépendance affichée, je cherche alors des bibliothèques simples (un seul fichier source). J'ai TinyXML et RapidJson dans cette catégorie. Et j'envisage sérieusement de supprimer ces deux dépendances bientôt et de ne passer que par un seul format d'entrée (j'en parlerai peut-être dans un journal bientôt). Et enfin, j'ai GameControllerDB qui contient des données uniquement et Google Test où c'est la manière recommandée de procéder.
Deuxièmement, j'ai des dépendances externes affichées. Là, j'essaie d'en avoir le minimum. J'ai SDL2, Freetype, Boost (seulement certaines parties) et récemment j'ai ajouté Zlib. Pour celles là, j'utilise mon gestionnaire de paquet préféré quand je suis sur Linux et j'utilise l'excellent vcpkg quand je suis sur Windows (j'inclus les plateformes de CI dans ces descriptions). Et ça marche plutôt bien. Je trouve vcpkg très bien foutu, en une seule ligne, on a tout ce qu'il faut prêt à l'emploi. On a une impression d'être à la maison (Linux) tellement c'est simple. En revanche, je déteste Conan cordialement. Je trouve le concept fumeux de base.