Si vous avez un fichier d'en-tête nommé thisisaheaderfile.h, les suivants localiseront toujours le fichier dans Visual Studio:
#include <ThisIsAheaderFile.h>
5 Réponses :
Vous ne pouvez pas, car le système de fichiers Windows est en soi insensible à la casse.
Si vous pouviez entrer dans une situation où vous aviez à la fois Richie.h et Richie.h, il pourrait être logique de contrôler la sensibilité des cas, mais vous ne pouvez pas.
Vous pouvez écrire si .. Inclut ... plaque de chaudière pour le faire pour chaque fichier.
En fait, ce n'est pas tout à fait raison. NTFS conserve le cas des noms de fichiers dans le cadre de la conformité du POSIX, mais carape tout en majuscule lors de l'exploitation de fichiers. blogs.msdn.com/michkap/archive/2005/01/ 16 / 353873.aspx
C ++ fonctionne plus que des zones de fenêtres.
Je me souviens d'avoir un problème où il s'est avéré qu'il y avait deux fichiers (Richie.h et Richie.h (ils ne diffèrent que dans le cas)) Gagner manipulé le premier qu'il a trouvé dans la structure de répertoire.
@Wolfmandragon: Cette question est spécifiquement sur Visual Studio.
@Wolfmandragon: Parce qu'il circule sur différentes plates-formes, il faut prendre en compte que certaines plates-formes ne sont tout simplement pas sensibles à la casse dans le système de fichiers. D'où le comportement.
@Richiehindle, et Chris animé, vous avez manqué le point de Wolfmandragon. Je cours très souvent dans ça. Notre équipe Windows Dev utilise Visual Studio et enfreint la construction Linux en raison d'en-têtes capitalisés incorrects. Beaucoup de cycles inutiles pourraient être éliminés s'il y avait un moyen de rendre CL.EXE être sensible à la casse pour inclure.
@ Lorenz03TX: Bon point, mais malheureusement, je ne crois pas que ce soit possible.
Visual Studio pourrait comparer sensiblement le nom du système de fichiers avec le nom de fichier de la déclaration INCLUS ... rien n'empêche cela.
Les systèmes de fichiers insensibles en cas de graisse et NTF. FOO et FOO sont le même fichier en ce qui concerne les choses concernées. Bien que Windows OS conserve le cas que vous utilisez pour un fichier. Si vous nommez un fichier thisisaheaderfile.h, il apparaît ainsi dans le système de fichiers. Bien que toute la fonction système appelle à l'ouverture de ce fichier puisse utiliser n'importe quel boîtier qu'ils veulent.
Non, NTFS est sensible à la casse (ou peut être faite avec un paramètre de registre). Win32, cependant, est insensible à la casse. Juste fyi, puisque la réponse est fausse et tout ...
C'est (l'habitude d'être?) possible de créer des fichiers avec le même nom, mais des différences de cas sur les NTFS. Peut-être que quelqu'un avec Cygwin peut vérifier cela.
Même alors, cependant, il est impossible d'accéder à plus d'une de ces personnes à la fois d'une application Windows normale.
Bien qu'il ne soit peut-être pas possible de l'appliquer à partir de Visual Studio, on pourrait implémenter une vérification rapide en exécutant uniquement le prétraiteur de la source C / C ++. Cela fonctionnera assez rapidement pour être praticable même comme un crochet post-validation dans un système de contrôle de la version, et ERR si le cas dans les noms de fichier a été incompatible. Donc:
Configurez votre système de construction sous Linux pour prendre en charge les exécutions du préprocesseur ( Implémenter un préprocesseur - Seule uniquement comme crochet post-validation, déclenchant une notification précoce à la personne responsable et / ou à une personne disposée à corriger régulièrement ces erreurs
Bien sûr, cela suppose un VCS en tant que stockage central pour le code. -e avec gcc / g ++ )
C'est une excellente solution, une autre constituerait un script simple ou un préprocesseur d'exécution comme pré-commis sur la machine de commissaires et laissez-vous nettoyer l'utilisateur lui-même.
@Daramarak: Comment cela aidera-t-il si le commissateur exécute un système de fichiers insensible à la casse?
Comme le script est capable de détecter le cas, et pendant que le préprocesseur MINGW est insensible à la casse (et il semble ne pas avoir aucune option pour la transformer), GCC en cygwin sera sensible à la casse.
Je voudrais souligner que ceci est Un tel contre-compteur est vraiment génial d'avoir lors du développement de la plate-forme croisée et empêche beaucoup après le travail lorsque le code est compilé pour l'autre plate-forme. Ne pas oublier que rendre le processus de construction plus difficile que vous induisiez de meilleures habitudes pour les développeurs, car ils seront progressivement plus cohérents comment ils incluent et nomment des fichiers.
TL; DR
Une solution consiste à utiliser un script qui scanne simplement les fichiers source pour inclure des déclarations et des essais pour les associer le long des chemins inclus. Un tel script pourrait être ajouté aux événements Visual Studio Post-Build, et à chaque construction, ou (inspiré par KRLMLR ) Utilisez le préprocesseur d'un compilateur qui appliquait la sensibilité des cas.
J'ai vu cela être un problème lorsque vous travaillez avec des bases de code UNIX pouvant utiliser deux versions du même nom de fichier, mais avec des cas différents.
Une des raisons pour laquelle cela serait utile, c'est pour Crossplatform Codebases où vous souhaitez que les développeurs Windows cessent d'insérer des erreurs de cas dans le codeBase.