Bonjour à tous et meilleurs voeux!

Ma question va être assez bête mais tant pis

Je fais quelques petits logiciels pour le taf (enfin...je ne programme pas non plus des OS hein ^^) et je suis amené à utiliser plusieurs fois les même classes. J'ai donc mes petites lib perso pour les réutiliser à chaque programme, mais pour l'instant c'était des classes toutes simples et ça m'évitais juste de retaper du code ou de bricoler avec des copier - coller

Au fur et à mesure des besoins, mes classes sont un peu plus élaborées (aucune prétention, c'est des trucs tout simples!) avec certaines qui vont avoir besoin d'autre classe se trouvant dans une autre lib donc là je me dis que je m'y prend mal et c'est pourquoi je post ce message

Quel est le meilleurs moyen de gérer un ensemble de lib perso?

Faire une solution Visual Studio pour faire un lib géante, et à chaque projet, j'inclurai uniquement les *h dont j'ai besoin?

J'avoue être un peu perdu sur ce point!

Merci d'avance pour vos lumières!

C'est vague comme question, on ne peut pas vraiment donner de solutions miracle qui fonctionnent partout. C'est au cas par cas.

Par exemple, si tu crées une unique classe en deux fichiers (un .cpp, un .h) et qui depend de rien du tout alors autant la garder dans un dépôt de « recueil » que tu copies dans chaque nouveau projet où tu en auras besoin. Contrairement aux développeurs node-js, en C et C++ ont fait rarement une bibliothèque pour une fonctionnalité unique comme eux. Et dieu merci.

Si tu as plusieurs classes qui sont dépendantes l'une de l'autres et donc indissociables, alors je recommanderais de les stocker dans un projet dédié à ça. Par exemple un lot de fonctions qui analysent des fichiers de types différents pour les amalgamer dans un autre format.

Pour ma part j'ai quelques « modules » (un parseur ini, un lot de fonction de chaîne de caractères, une gestion unicode) et je les copie dans les projets où j'en ai besoin et les rajoute à la compilation.

Bonjour Asphodelus,

Je n'ai pas une grande expérience dans ce domaine, je me permets quand même un conseil que j'applique : Pour ne pas te perdre dans l'origine des "lib", utilise un namespace pour identifier ce qui est une lib/objet à toi. Ça permet du premier coup d'œil d'identifier l'origine. Pour ma part, j'ai mis mes initiales (pour ne pas être trop long à entrer).

Cordialement.

@markand, je me doute que ma question est un peu vaste désolé et du coup, si je comprend bien, ce que je fais actuellement n'est pas déconnant

@Dedeun, oui merci à toi, je fais déjà ça pour m'y retrouver

Salut,

Avec visual Studio tu peux faire la chose suivante :

Quand tu créés un projet, tu peux créer une librairie statique : ça te crée un vcproj dans lequel tu peux mettre toutes ta classes, ou bien les classes d'un type de lib que tu fais.

Tu peux faire cela plusieurs fois si tu le souhaites pour avoir plusieurs libs.

Ensuite quand tu crées un projet (une solution sln, ça te crée aussi un vcproj, tu peux choisir de charger d'autres projets, tu charges les vcproj des lib dont tu as besoin). Ainsi, avec ton projet tu as accès aux sources de tes libs que tu peux modifier. Et si d'autres projets partagent ces libs, alors la modification affectera tous les projets qui l'utilise.

Pour résumer, soit tu considères une lib déjà compilée (comme quand tu link SDL par exemple), mais tu ne peux pas la modifier dans ton projet)

Soit tu considères un sln avec plusieurs vcproj, et tu peux modifier les sources de ta lib comme d'autres sources.

Pour moi :

- Eviter au maximum les dépendances entre classes (utilisation d'inversion de dépendance, etc...), pour pouvoir facilement m'en servir ailleurs, et les configurer au besoin final

- Regrouper les classes en module gérants les mêmes types d'objets/fonctionnalités avec un même niveau d'abstraction.

- Si des classes utilisent d'autres classes pour implémenter les fonctionnalités mais avec un niveau d'abstraction plus faible, ne pas mélanger ces classes dans un seul module mais dans plusieurs, (en fonction des différents niveaux d'abstraction). Si c'est bien fait, il sera même possible de séparer ces couches d'abstractions en différentes librairies/bibliothèques.

- Faire en sorte que chaque librairie/bibliothèque est un contenu de niveau d'abstraction "cohérent" et que l'utilisation de ces bibliothèques ne "génèrent" pas de cycle. Qu'une classe de la librairie A ait besoin d'une classe de la librairie B qui elle-même ait besoin d'une classe de la librairie A et c'est la fin des haricots. En ayant des niveaux d'abstraction différents, ces cycles ne devraient pas apparaître.

- Plus il y a de chose dans une librairie plus les mises à jours seront lourdes en terme de taille mémoire mais la gestion du versioning sera plus simple. Avec beaucoup de librairies, la gestion du versioning est beaucoup plus lourde.

- etc...

Il y a donc pas de "règles absolues" mais quelques règles de bon sens et une bonne analyse des besoins actuels mais aussi futurs.

-
Edité par bacelar 12 janvier 2021 à 19:52:58

Merci à tous pour vos réponses!

Disons que je suis en train de faire un projet "Template" avec les fonctionnalités de base

J'ai par exemple une classe "Customer" qui hérite de "Person", qui utilise une struc "Adress", une autre classe qui gère les plannings etc etc....

Donc pas de quoi sauter au plafond...du coup ce serait conventionnel que gérer une lib géante avec tout ça dedans pour pouvoir l'utiliser dans différents projets (et donc de mofidier le "Template" quand j'en aurai besoin, pour que les modifs soient prisent en compte dans les programmes utilisant cette lib?

(du coup peut être partir sur la solution de Fvirtman?)

-
Edité par Anonyme 12 janvier 2021 à 19:32:36

C'est une histoire de compromis, il n'y a pas de "bonnes" réponses.

Ce qu'indique @Fvirtman, c'est une manière de faire. Les compromis entre grosses librairies monolithiques et petites librairies indépendantes, c'est fonction du type d'utilisation envisagé.

Mais il est toujours facile de regrouper de petites librairies indépendantes en une grosse alors que fragmenter une grosse librairie monolithique en plusieurs éléments est beaucoup plus aléatoire.

Dans votre cas, le plus gros "problème" que je vois avec une seule librairie "géante", c'est que pour tout module, même indépendant des autres et non utilisé par une grosse partie des projets "clients" de la librairie, vous devrez recompiler toutes les applications qui se servent peu ou prou de votre librairie et que des classes utilisables que pour les tests, par exemple, seront dedans.