Partager via

Erreur irrécupérable C1083

  • Article

Impossible d’ouvrir le fichier filetype : ' file' : message

Le compilateur génère une erreur C1083 lorsqu’il ne trouve pas de fichier. Il existe de nombreuses causes possibles pour cette erreur. Un chemin de recherche incorrect ou des fichiers d’en-tête mal nommés ou manquants est les causes les plus courantes, mais d’autres types de fichiers et problèmes peuvent également entraîner L’erreur C1083. Voici quelques-unes des raisons courantes pour lesquelles le compilateur génère cette erreur.

Le nom de fichier spécifié est erroné

Le nom d’un fichier peut être mal typé. Par exemple,

#include <algorithm.h>

ne trouve peut-être pas le fichier souhaité. La plupart des fichiers d’en-tête de la bibliothèque standard C++ n’ont pas d’extension .h de nom de fichier. Cette #include directive ne trouve pas l’en-tête <algorithm> . Pour résoudre ce problème, vérifiez que le nom de fichier correct est entré, comme suit :

#include <algorithm>

Certains en-têtes de la bibliothèque runtime C sont situés dans un sous-répertoire du répertoire Include standard. Par exemple, pour inclure sys/types.h, vous devez inclure le nom du sys sous-répertoire dans la #include directive :

#include <sys/types.h>

Le fichier n’est pas inclus dans le chemin de recherche Include

Le compilateur ne peut pas trouver le fichier à l’aide des règles de recherche pour la ou #import la #include directive. Par exemple, lorsqu’un nom de fichier d’en-tête est placé entre guillemets,

#include "myincludefile.h"

cela indique au compilateur de rechercher le fichier dans le même répertoire que celui qui contient le fichier source en premier, puis de rechercher dans d’autres emplacements spécifiés par l’environnement de build. Si les guillemets contiennent un chemin d’accès absolu, le compilateur recherche uniquement le fichier à cet emplacement. Si les guillemets contiennent un chemin d'accès relatif, le compilateur recherche le fichier dans le répertoire relatif au répertoire source.

Si le nom est placé entre crochets d’angle,

#include <stdio.h>

le compilateur suit un chemin de recherche défini par l’environnement de génération, l’option /I du compilateur, l’option /X du compilateur et la variable d’environnement INCLUDE . Pour plus d’informations, y compris des détails spécifiques sur l’ordre de recherche utilisé pour rechercher un fichier, consultez #include Directive (C/C++) et #import Directive.

Si vos fichiers include se trouvent dans un autre répertoire par rapport à votre répertoire source et que vous utilisez un chemin relatif dans vos directives include, vous devez utiliser des guillemets doubles plutôt que des crochets angle. Par exemple, si votre fichier myheader.h d’en-tête se trouve dans un sous-répertoire de vos sources de projet nommées en-têtes, cet exemple ne trouve pas le fichier et provoque L’erreur C1083 :

#include <headers\myheader.h>

mais cet exemple fonctionne :

#include "headers\myheader.h"

Les chemins relatifs peuvent également être utilisés avec des répertoires sur le chemin d’accès de recherche Include. Si vous ajoutez un répertoire à la variable d’environnement INCLUDE ou à votre chemin Include Directories dans Visual Studio, n’ajoutez pas une partie du chemin d’accès aux directives include. Par exemple, si votre en-tête se trouve à l’emplacement \path\example\headers\myheader.h, et que vous ajoutez \path\example\headers\ à votre chemin d’accès Répertoires Include dans Visual Studio, mais que votre #include directive fait référence au fichier en tant que

#include <headers\myheader.h>

le fichier n’est pas trouvé. Utilisez le chemin d’accès correct par rapport au répertoire spécifié dans le chemin d’accès de recherche Include. Dans cet exemple, vous pouvez modifier le chemin d’accès de recherche include en \path\example\, ou supprimer le segment de headers\ chemin d’accès de la #include directive.

Problèmes liés aux bibliothèques tierces et vcpkg

Si vous voyez cette erreur lorsque vous essayez de configurer une bibliothèque tierce dans le cadre de votre build, envisagez d’utiliser vcpkg, un gestionnaire de package C++, pour installer et générer la bibliothèque. vcpkg prend en charge une liste importante et croissante de bibliothèques tierces, et définit toutes les propriétés et dépendances de configuration requises pour les builds réussies dans le cadre de votre projet.

Le fichier se trouve dans votre projet, mais pas le chemin d’accès de recherche Include

Même lorsque les fichiers d’en-tête sont répertoriés dans Explorateur de solutions dans le cadre d’un projet, les fichiers sont trouvés uniquement par le compilateur lorsqu’ils sont référencés par une #include ou #import une directive dans un fichier source et se trouvent dans un chemin de recherche include. Différents genres de builds peuvent utiliser différents chemins d’accès de recherche. L’option /X du compilateur peut être utilisée pour exclure les répertoires du chemin d’accès de recherche Include. Cela permet à des builds distinctes d'utiliser des fichiers Include distincts qui portent le même nom, mais qui sont conservés dans des dossiers différents. Il s'agit d'une alternative à la compilation conditionnelle à l'aide de commandes de préprocesseur. Pour plus d’informations sur l’option du /X compilateur, consultez /X (Ignorer les chemins d’accès Include Standard).

Pour résoudre ce problème, corrigez le chemin d'accès utilisé par le compilateur pour rechercher le fichier inclus ou importé. Un nouveau projet utilise les chemins de recherche par défaut. Vous devrez peut-être modifier le chemin d’accès de recherche include pour ajouter un répertoire pour votre projet. Si vous compilez sur la ligne de commande, ajoutez le chemin d’accès à la variable d’environnement INCLUDE ou l’option /I du compilateur pour spécifier le chemin d’accès au fichier.

Pour définir le chemin d’accès du répertoire include dans Visual Studio, ouvrez la boîte de dialogue Pages de propriétés du projet. Sélectionnez Répertoires VC++ sous Propriétés de configuration dans le volet gauche, puis modifiez la propriété Include Directories. Pour plus d’informations sur les répertoires par utilisateur et par projet recherchés par le compilateur dans Visual Studio, consultez la page de propriétés des répertoires VC++. Pour plus d’informations sur l’option du /I compilateur, consultez /I (Répertoires Include supplémentaires).

L’environnement INCLUDE ou LIB de la ligne de commande n’est pas défini

Lorsque le compilateur est appelé sur la ligne de commande, les variables d'environnement sont souvent utilisées pour spécifier des chemins de recherche. Si le chemin de recherche décrit par la variable d’environnement INCLUDE ou LIB n’est pas défini correctement, une erreur C1083 peut être générée. Nous vous recommandons vivement d’utiliser un raccourci d’invite de commandes développeur pour définir l’environnement de base pour les builds de ligne de commande. Pour plus d’informations, consultez Générer C/C++ sur la ligne de commande. Pour plus d’informations sur l’utilisation des variables d’environnement, consultez Guide pratique pour utiliser des variables d’environnement dans une build.

Le fichier peut être verrouillé ou en cours d’utilisation

Si vous utilisez un autre programme pour modifier ou accéder au fichier, il se peut que le fichier soit verrouillé. Essayez de fermer le fichier dans l’autre programme. Parfois, l’autre programme peut être Visual Studio lui-même, si vous utilisez des options de compilation parallèles. Si l’option de génération parallèle désactive l’erreur, il s’agit du problème. D’autres systèmes de génération parallèle peuvent également avoir ce problème. Veillez à définir les dépendances de fichier et de projet afin que l’ordre de génération soit correct. Dans certains cas, envisagez de créer un projet intermédiaire pour forcer l’ordre de dépendance de génération pour un fichier commun qui peut être généré par plusieurs projets. Parfois, les programmes antivirus verrouillent temporairement les fichiers récemment modifiés pour l’analyse. Si possible, envisagez d’exclure les répertoires de build de votre projet à partir du scanneur antivirus.

La version incorrecte d'un nom de fichier est incluse

Une erreur C1083 peut également indiquer que la version incorrecte d'un fichier a été incluse. Par exemple, une build peut inclure la version incorrecte d’un fichier qui a une #include directive pour un fichier d’en-tête qui n’est pas destiné à cette build. Par exemple, certains fichiers peuvent uniquement s’appliquer aux builds x86 ou aux builds de débogage. Lorsque le fichier d’en-tête est introuvable, le compilateur génère une erreur C1083. Pour résoudre ce problème, utilisez le fichier approprié. N'ajoutez pas le fichier d'en-tête ou le répertoire à la build.

Les en-têtes précompilés ne sont pas encore précompilés

Lorsqu’un projet est configuré pour utiliser des en-têtes précompilés, les fichiers pertinents .pch doivent être créés afin que les fichiers qui utilisent le contenu de l’en-tête puissent être compilés. Par exemple, le pch.cpp fichier (stdafx.cpp dans Visual Studio 2017 et versions antérieures) est créé automatiquement dans le répertoire du projet pour les nouveaux projets. Compilez d’abord ce fichier pour créer les fichiers d’en-tête précompilés. Dans la conception classique du processus de génération, cette opération est effectuée automatiquement. Pour plus d’informations, consultez Création de fichiers d’en-tête précompilés.

Autres causes

  • Vous avez installé un Kit de développement logiciel (SDK) ou une bibliothèque tierce, mais n’avez pas ouvert une nouvelle invite de commandes développeur. Si le SDK ou la bibliothèque ajoute des fichiers au chemin INCLUDE , vous devrez peut-être ouvrir une nouvelle fenêtre d’invite de commandes développeur pour récupérer ces modifications de variable d’environnement.

  • Le fichier utilise du code managé, mais l’option /clr du compilateur n’est pas spécifiée. Pour plus d’informations, consultez /clr (Compilation Common Language Runtime).

  • Le fichier est compilé à l’aide d’un paramètre d’option de compilateur différent /analyze de celui utilisé pour précompiler les en-têtes. Lorsque les en-têtes d’un projet sont précompilés, tous doivent utiliser les mêmes /analyze paramètres. Pour plus d’informations, consultez /analyze (Analyse du code).

  • Le fichier ou le répertoire a été créé par l’Sous-système Windows pour Linux, la sensibilité à la casse par répertoire est activée et la casse spécifiée d’un chemin d’accès ou d’un fichier ne correspond pas au cas du chemin d’accès ou du fichier sur le disque.

  • Le fichier, le répertoire ou le disque est en lecture seule.

  • Visual Studio ou les outils en ligne de commande ne disposent pas des autorisations suffisantes pour lire le fichier ou le répertoire. Cela peut se produire, par exemple, lorsque les fichiers projet ont une propriété différente du processus exécutant Visual Studio ou les outils en ligne de commande. Parfois, ce problème peut être résolu en exécutant Visual Studio ou l’invite de commandes développeur en tant qu’administrateur.

  • Il n’y a pas assez de handles de fichiers. Fermez certaines applications, puis recompilez. Cette situation est inhabituelle dans des circonstances normales. Toutefois, elle peut se produire lorsque des projets de grande taille sont générés sur un ordinateur dont la mémoire physique est limitée.

Exemple

L’exemple suivant génère une erreur C1083 lorsque le fichier "test.h" d’en-tête n’existe pas dans le répertoire source ou dans le chemin de recherche include.

// C1083.cpp
// compile with: /c
#include "test.h"   // C1083 test.h doesn't exist
#include "stdio.h"  // OK

Pour plus d’informations sur la création de projets C/C++ dans l’IDE ou sur la ligne de commande et des informations sur la définition des variables d’environnement, consultez Projets et systèmes de génération.

Voir aussi