Meilleures pratiques pour créer une application qui sera fréquemment mise à jour - C++

Question

Je suis en train de développer une application portable en C++ et je suis à la recherche des meilleures pratiques pour ce faire. Cette application fera l'objet de mises à jour fréquentes et je dois la construire de manière à ce que certaines parties du programme puissent être mises à jour facilement.

1. Pour un programme fréquemment mis à jour, la meilleure pratique consiste à créer les parties du programme dans des bibliothèques. Si les parties de programme sont dans des bibliothèques séparées, les utilisateurs peuvent simplement remplacer la bibliothèque lorsque quelque chose change.
2. Si la réponse au point 1 est "oui", quel type de bibliothèque dois-je utiliser ? Sous LINUX, je sais que je peux créer une bibliothèque " bibliothèque partagée "mais je ne suis pas sûr qu'il soit possible de le transférer sous Windows. Quel type de bibliothèque dois-je utiliser ? Je suis également conscient des problèmes liés aux DLL sous Windows.

Toute aide serait la bienvenue !

Answer 1

1. Oui, l'utilisation de bibliothèques est une bonne chose, mais l'idée de remplacer "simplement" une bibliothèque par une nouvelle peut être irréaliste, car les API des bibliothèques ont tendance à changer et les applications doivent souvent être mises à jour pour tirer parti des différentes versions d'une bibliothèque, voire pour être compatibles avec elles. Avec une bonne quantité de tests d'intégration Cependant, vous serez en mesure de "soutenir" une série de versions différentes de la bibliothèque. Ou, si vous contrôlez vous-même le code de la bibliothèque, vous pouvez vous assurer que les modifications apportées au code de la bibliothèque n'interrompent jamais l'application.

2. Dans Windows, les DLL sont l'équivalent direct des bibliothèques partagées (so) dans Linux, et si vous compilez les deux dans un environnement commun (soit par compilation croisée, soit en utilisant MingW dans Windows), l'éditeur de liens le fera de la même manière. En supposant, bien sûr, que tout le reste de votre code soit multiplateforme et se configure correctement pour la plateforme cible.

   IMO, L'enfer des DLL était davantage un problème à l'époque où les applications installaient toutes leurs DLL dans un répertoire commun tel que C:\WINDOWS\SYSTEM ce que les gens ne font plus vraiment, simplement parce que cela crée un enfer de DLL. Vous pouvez placer vos bibliothèques partagées dans un endroit plus approprié où elles n'interféreront pas avec d'autres applications qui ne les connaissent pas, ou - ce qui est le plus simple - les placer dans le même répertoire que l'exécutable qui en a besoin.

Answer 2

Je ne suis pas entièrement convaincu que la séparation des parties exécutables de votre programme simplifie en quoi que ce soit les mises à jour. Cela pourrait, peut-être, dans de rares cas, réduire la taille de l'installateur de la mise à jour, mais l'effort sera considérable et ne vaudra certainement pas la peine la seule fois où vous l'obtiendrez erroné . Remplacer tous les codes exécutables par un seul dans la plupart des cas.

D'un autre côté, vous devez faire très attention à ne pas modifier ce que vos utilisateurs ont pu changer. Tracez une ligne claire entre la partie de l'application qui n'est que du code et la partie qui correspond aux données de l'utilisateur. Manipulez les données de l'utilisateur avec précaution.

Answer 3

S'il s'agit d'une application, mon premier choix serait de livrer un exécutable unique lié statiquement. J'ai eu l'occasion de travailler sur un produit qui a été livré sur 5 plateformes (Win2K, WinXp, Linux, Solaris, Tru64-Unix), et croyez-moi, maintenir des bibliothèques partagées ou des DLL avec une base de code importante est une tâche infernale. Supposons qu'il s'agisse d'une application non triviale qui implique l'utilisation d'une interface graphique tierce, de threads, etc. En utilisant le C++, il n'y a pas de véritable à sens unique de le faire sur toutes les plateformes. Cela signifie que vous devrez de toute façon maintenir des bases de code différentes pour les différentes plates-formes. Il y a aussi des comportements bizarres (bugs) de bibliothèques tierces sur différentes plates-formes. Tout cela crée un fardeau si l'application est livrée en utilisant différentes versions de la bibliothèque, c'est-à-dire que différentes versions doivent être attachées à différentes plates-formes. J'ai vu des personnes livrer des bibliothèques pour toutes les plateformes alors que la correction ne concernait qu'une plateforme particulière, simplement pour éviter la confusion des versions. Mais ce n'est pas si simple, le client a souvent un point de vue différent sur la manière dont il souhaite mettre à jour ou apporter des correctifs, ce qui doit également être pris en compte.

Bien sûr, si le binaire que vous construisez est volumineux, vous pouvez envisager les DLL/librairies partagées. Même si c'est le cas, ce que je suggérerais, c'est de construire votre application sous la forme de couches comme:- Application-->GUI-->Plateforme-->Base-->Fondamental

Ainsi, certaines bibliothèques peuvent avoir un code commun pour toutes les plates-formes. Seules des bibliothèques spécifiques comme "Platform" peuvent être mises à jour pour des comportements spécifiques. Cela vous facilitera grandement la vie.

L'option DLL/bibliothèque partagée est viable lorsque vous construisez un produit qui agit comme une solution complète plutôt que comme une simple application. Dans ce cas, différents sous-systèmes utilisent simultanément une logique commune dans le cadre de votre produit, logique qui peut alors être partagée en mémoire à l'aide de DLL/bibliothèques partagées.

HTH,

Answer 4

Dès que vous essayez de traiter avec les à la fois Windows et un système UNIX comme Linux, la vie se complique.

Quelles sont les exigences en matière de services que vous devez satisfaire ? Pouvez-vous contrôler le moment où les systèmes des clients sont mis à niveau ? Combien de systèmes devrez-vous prendre en charge ? Quel est le degré d'exigence en matière de compatibilité ascendante ?

Answer 5

Pour répondre à votre question par une question, pourquoi rendre l'application native si la portabilité est l'un des principaux objectifs ?

Vous pourriez envisager de passer à une plate-forme virtuelle comme Java ou .Net/Mono. Vous pouvez toujours écrire des bibliothèques C++ (bibliothèques partagées sous Linux, DLL sous Windows) pour tout ce qui serait mieux en code natif, mais l'essentiel de votre application sera réellement portable.