Est-il autorisé à mélanger différentes fonctions de gestion de fichiers dans un système unique, par ex.routines de gestion de fichiers sous Windows
J'ai une grande application avec beaucoup de code hérité et il semble que les trois méthodes sont utilisées dans ce code. Quels sont les risques potentiels et les effets secondaires?
Oui, vous pouvez mélanger tout cela ensemble. Tout se résume à l'appel CreateFile dans tous les cas.
Bien sûr, vous ne pouvez pas passer un pointeur de fichier à CloseHandle et espérer qu'il fonctionne, ne peut vous attendre à une poignée ouvert de CreateFile à travailler avec fclose. Pensez-y exactement comme vous le pensez malloc/free vs new/delete en C++. Parfaitement bien d'utiliser simultanément tant que vous ne les mélangez pas.
Il est parfaitement correct d'utiliser toutes ces méthodes de fichiers, tant qu'elles n'ont pas besoin d'interagir. La minute où vous devez passer un fichier ouvert avec une méthode dans une fonction qui suppose une méthode différente, vous trouverez qu'ils sont incompatibles.
En ce qui concerne le style, je recommanderais d'en choisir un et de le coller, mais si le code provient de plusieurs sources, cela pourrait ne pas être possible. Ce serait un gros effort de refactoring pour changer le code existant, sans beaucoup de gain.
Votre situation n'est pas si rare.
Le code conçu pour être portable est généralement écrit en utilisant des routines d'accès aux fichiers standard (fopen, open, etc.). Le code spécifique au système d'exploitation est généralement écrit à l'aide de l'API native de ce système d'exploitation. Votre grande application est très probablement une combinaison de ces deux types de code. Vous ne devriez avoir aucun problème à mélanger les styles d'accès au fichier dans le même programme tant que vous vous souvenez de les garder droits (ils ne sont pas interchangeables).
Le plus grand risque impliqué ici est probablement la portabilité. Si vous avez du code hérité qui existe depuis un certain temps, il utilise probablement les méthodes d'accès au fichier C/C++ standard, surtout s'il est antérieur à l'API Win32. L'utilisation de l'API Win32 est acceptable, mais vous devez réaliser que vous liez votre code à la portée et à la durée de vie de cette API. Vous devrez faire un travail supplémentaire pour porter ce code sur une autre plateforme. Vous devrez également retravailler ce code si, disons, dans le futur Microsoft obsolète l'API Win32 en faveur de quelque chose de nouveau. Les méthodes standard C/C++ seront toujours là, constantes et immuables. Si vous voulez aider à pérenniser votre code, respectez les méthodes et fonctions standard autant que possible. En même temps, certaines choses nécessitent l'API Win32 et ne peuvent pas être réalisées avec des fonctions standard. Si vous travaillez avec un mélange de style C, de style C++ et de code Win32, je vous suggère de séparer (autant que possible raisonnablement) votre code spécifique au système d'exploitation et votre code portable modules avec des API bien définies. Si vous devez réécrire votre code Win32 à l'avenir, cela peut faciliter les choses.