Fatal error c1083 не удается открыть файл включение crtdbg h no such file or directory

I am trying to compile the cpp code in visual studio 2013. It was working fine earlier. But now I am getting following error:

Error 1 error C1083: Cannot open include file: ‘crtdbg.h’: No such
file or directory C:Program Files (x86)Microsoft Visual Studio
12.0VCatlmfcincludeafx.h 250 1 IDEditor

I checked crtdbg.h. This file exist in "C:Program Files (x86)Microsoft Visual Studio 12.0VCinclude" path.

Looks like it is not able to include above directory.
I tried adding path in properties but still getting same problem.

$(VC_IncludePath);$(WindowsSDK_IncludePath);C:Program Files (x86)Microsoft Visual Studio 12.0VCinclude

Please help

Roman Marusyk

22.6k24 gold badges70 silver badges112 bronze badges

asked Oct 13, 2015 at 13:53

I have resolved this issue, by adding manually the missing files :
crtdbg.h then ucrt.lib.

crtdbg.h

Select : VC++ Repositories => Menu General => include repositories

Add:(Exemple for me, on x64 platform, you can search where is located this file in your machine then add the correct path)
```
C:Program Files (x86)Windows Kits10Include10.0.19041.0ucrt
```
ucrt.lib

Select : links editor => additional library directories

Add:(Exemple for me, on x64 platform, you can search where is located this file
in your machine then add the correct path)
```
C:Program Files (x86)Windows Kits10Lib10.0.19041.0ucrtx64
```
Clean your project then rebuild and execute the project.

You should have no errors and a compilation successfull then the console display «Hello world».

Christopher

2,9041 gold badge11 silver badges27 bronze badges

answered Apr 10, 2022 at 12:12

I think that Visual Studio can’t access to header file, crtdbg.h , Pease test a simple following way. Maybe it solve your problem:

1- Run as administrator Visual Studio. I emphasized run as administrator no run.

2- Open your project.

3- Add the include path in the properties.

4- Happy coding and enjoy it.

answered Nov 17, 2020 at 15:05

Источник

description	title	ms.date	f1_keywords	helpviewer_keywords	ms.assetid
Learn more about: Fatal Error C1083	Fatal Error C1083	09/01/2017	C1083	C1083	97e52df3-e79c-4f85-8f1e-bbd1057d55e7

Cannot open filetype file: ‘file‘: message

The compiler generates a C1083 error when it can’t find a file it requires. There are many possible causes for this error. An incorrect include search path or missing or misnamed header files are the most common causes, but other file types and issues can also cause C1083. Here are some of the common reasons why the compiler generates this error.

The specified file name is wrong

The name of a file may be mistyped. For example,

#include <algorithm.h>

might not find the file you intend. Most C++ Standard Library header files do not have a .h file name extension. The <algorithm> header would not be found by this #include directive. To fix this issue, verify that the correct file name is entered, as in this example:

#include <algorithm>

Certain C Runtime Library headers are located in a subdirectory of the standard include directory. For example, to include sys/types.h, you must include the sys subdirectory name in the #include directive:

#include <sys/types.h>

The file is not included in the include search path

The compiler cannot find the file by using the search rules that are indicated by an #include or #import directive. For example, when a header file name is enclosed by quotation marks,

#include "myincludefile.h"

this tells the compiler to look for the file in the same directory that contains the source file first, and then look in other locations specified by the build environment. If the quotation marks contain an absolute path, the compiler only looks for the file at that location. If the quotation marks contain a relative path, the compiler looks for the file in the directory relative to the source directory.

If the name is enclosed by angle brackets,

#include <stdio.h>

the compiler follows a search path that is defined by the build environment, the /I compiler option, the /X compiler option, and the INCLUDE environment variable. For more information, including specific details about the search order used to find a file, see #include Directive (C/C++) and #import Directive.

If your include files are in another directory relative to your source directory, and you use a relative path in your include directives, you must use double quotes instead of angle brackets. For example, if your header file myheader.h is in a subdirectory of your project sources named headers, then this example fails to find the file and causes C1083:

#include <headersmyheader.h>

but this example works:

#include "headersmyheader.h"

Relative paths can also be used with directories on the include search path. If you add a directory to the INCLUDE environment variable or to your Include Directories path in Visual Studio, do not also add part of the path to the include directives. For example, if your header is located at pathexampleheadersmyheader.h, and you add pathexampleheaders to your Include Directories path in Visual Studio, but your #include directive refers to the file as

#include <headersmyheader.h>

then the file is not found. Use the correct path relative to the directory specified in the include search path. In this example, you could change the include search path to pathexample, or remove the headers path segment from the #include directive.

Third-party library issues and vcpkg

If you see this error when you are trying to configure a third-party library as part of your build, consider using vcpkg, a C++ package manager, to install and build the library. vcpkg supports a large and growing list of third-party libraries, and sets all the configuration properties and dependencies required for successful builds as part of your project.

The file is in your project, but not the include search path

Even when header files are listed in Solution Explorer as part of a project, the files are only found by the compiler when they are referred to by an #include or #import directive in a source file, and are located in an include search path. Different kinds of builds might use different search paths. The /X compiler option can be used to exclude directories from the include search path. This enables different builds to use different include files that have the same name, but are kept in different directories. This is an alternative to conditional compilation by using preprocessor commands. For more information about the /X compiler option, see /X (Ignore Standard Include Paths).

To fix this issue, correct the path that the compiler uses to search for the included or imported file. A new project uses default include search paths. You may have to modify the include search path to add a directory for your project. If you are compiling on the command line, add the path to the INCLUDE environment variable or the /I compiler option to specify the path to the file.

To set the include directory path in Visual Studio, open the project’s Property Pages dialog box. Select VC++ Directories under Configuration Properties in the left pane, and then edit the Include Directories property. For more information about the per-user and per-project directories searched by the compiler in Visual Studio, see VC++ Directories Property Page. For more information about the /I compiler option, see /I (Additional Include Directories).

The command line INCLUDE or LIB environment is not set

When the compiler is invoked on the command line, environment variables are often used to specify search paths. If the search path described by the INCLUDE or LIB environment variable is not set correctly, a C1083 error can be generated. We strongly recommend using a developer command prompt shortcut to set the basic environment for command line builds. For more information, see Build C/C++ on the Command Line. For more information about how to use environment variables, see How to: Use Environment Variables in a Build.

The file may be locked or in use

If you are using another program to edit or access the file, it may have the file locked. Try closing the file in the other program. Sometimes the other program can be Visual Studio itself, if you are using parallel compilation options. If turning off the parallel build option makes the error go away, then this is the problem. Other parallel build systems can also have this issue. Be careful to set file and project dependencies so build order is correct. In some cases, consider creating an intermediate project to force build dependency order for a common file that may be built by multiple projects. Sometimes antivirus programs temporarily lock recently changed files for scanning. If possible, consider excluding your project build directories from the antivirus scanner.

The wrong version of a file name is included

A C1083 error can also indicate that the wrong version of a file is included. For example, a build could include the wrong version of a file that has an #include directive for a header file that is not intended for that build. For example, certain files may only apply to x86 builds, or to Debug builds. When the header file is not found, the compiler generates a C1083 error. The fix for this problem is to use the correct file, not to add the header file or directory to the build.

The precompiled headers are not yet precompiled

When a project is configured to use precompiled headers, the relevant .pch files have to be created so that files that use the header contents can be compiled. For example, the pch.cpp file (stdafx.cpp in Visual Studio 2017 and earlier) is automatically created in the project directory for new projects. Compile that file first to create the precompiled header files. In the typical build process design, this is done automatically. For more information, see Creating Precompiled Header Files.

Additional causes

You have installed an SDK or third-party library, but you have not opened a new developer command prompt window after the SDK or library is installed. If the SDK or library adds files to the INCLUDE path, you may need to open a new developer command prompt window to pick up these environment variable changes.
The file uses managed code, but the compiler option /clr is not specified. For more information, see /clr (Common Language Runtime Compilation).
The file is compiled by using a different /analyze compiler option setting than is used to precompile the headers. When the headers for a project are precompiled, all should use the same /analyze settings. For more information, see /analyze (Code Analysis).
The file or directory was created by the Windows Subsystem for Linux, per-directory case sensitivity is enabled, and the specified case of a path or file does not match the case of the path or file on disk.
The file, the directory, or the disk is read-only.
Visual Studio or the command line tools do not have sufficient permissions to read the file or the directory. This can happen, for example, when the project files have different ownership than the process running Visual Studio or the command line tools. Sometimes this issue can be fixed by running Visual Studio or the developer command prompt as Administrator.
There are not enough file handles. Close some applications and then recompile. This condition is unusual under typical circumstances. However, it can occur when large projects are built on a computer that has limited physical memory.

Example

The following example generates a C1083 error when the header file "test.h" does not exist in the source directory or on the include search path.

// C1083.cpp
// compile with: /c
#include "test.h"   // C1083 test.h does not exist
#include "stdio.h"  // OK

For information about how to build C/C++ projects in the IDE or on the command line, and information about setting environment variables, see Projects and build systems.

Неустранимая ошибка C1083

Компилятор создает ошибку C1083, если не удается найти необходимый файл. Эта ошибка имеет несколько возможных причин. Неправильный путь поиска или отсутствующие или неправильно именуемые файлы заголовков являются наиболее распространенными причинами, но другие типы файлов и проблемы также могут вызвать C1083. Ниже приведены некоторые распространенные причины, по которым компилятор создает эту ошибку.

Указано неверное имя файла

При вводе имени файла допущена ошибка. Например, примененная к объекту директива

может не найти файл, который вы хотели. Большинство файлов заголовков стандартной библиотеки C++ не имеют расширения H-файла. Заголовок не найден этой #include директивой. Чтобы устранить эту проблему, убедитесь, что введено правильное имя файла, как в следующем примере:

Некоторые заголовки библиотеки времени выполнения C расположены в подкаталоге стандартного каталога включения. Например, чтобы включить sys/types.h , необходимо включить sys имя подкаталога в директиву #include :

Файл не включен в путь поиска включения

Компилятору не удается найти файл, используя правила поиска, которые указаны в директиве #include или #import . Например, если имя файла заголовка заключено в кавычки,

это указывает компилятору сначала искать файл в том же каталоге, который содержит исходный файл, а затем искать в других расположениях, указанных средой сборки. Если кавычки содержат абсолютный путь, компилятор выполняет поиск файла только в этом расположении. Если кавычки содержат относительный путь, компилятор выполняет поиск файла в каталоге относительно исходного каталога.

Если имя заключено в угловые скобки,

компилятор следует пути поиска, определяемого средой сборки, /I параметром компилятора, /X параметром компилятора и переменной среды INCLUDE . Дополнительные сведения, включая конкретные сведения о порядке поиска, используемом для поиска файла, см. в директиве #include (C/C++) и директиве #import.

Если файлы включения находятся в другом каталоге относительно исходного каталога и используете относительный путь в директивах include, следует использовать двойные кавычки вместо угловых скобок. Например, если файл myheader.h заголовка находится в подкаталоге источников проекта с именами заголовков, в этом примере не удается найти файл и вызвать C1083:

но этот пример работает:

Относительные пути также можно использовать с каталогами в пути поиска включения. Если вы добавляете каталог в переменную среды INCLUDE или в путь include directories в Visual Studio, не добавляйте часть пути к директивам include. Например, если заголовок находится по адресу pathexampleheadersmyheader.h и добавляется pathexampleheaders в путь включения каталогов в Visual Studio, но директива #include ссылается на файл как

затем файл не найден. Используйте правильный путь относительно каталога, указанного в пути поиска include. В этом примере можно изменить путь pathexample поиска включения или удалить headers сегмент пути из директивы #include .

Проблемы со сторонними библиотеками и vcpkg

Если эта ошибка возникает при попытке настроить стороннюю библиотеку в рамках сборки, рассмотрите возможность использования vcpkg, диспетчера пакетов C++ для установки и сборки библиотеки. vcpkg поддерживает большой и растущий список сторонних библиотек и задает все свойства и зависимости конфигурации, необходимые для успешных сборок в рамках проекта.

Файл находится в проекте, но не включает путь поиска

Даже если файлы заголовков перечислены в Обозреватель решений как часть проекта, файлы обнаруживаются компилятором только в том случае, если они ссылаются #include на исходный файл или #import директиву и находятся в пути поиска включаемых файлов. Для различных типов построений могут использоваться разные пути поиска. Параметр /X компилятора можно использовать для исключения каталогов из пути поиска включения. Это позволяет использовать для разных построений разные файлы include, которые имеют одно имя, но расположены в разных каталогах. Таким образом создается альтернатива условной компиляции с помощью команд препроцессора. Дополнительные сведения о параметре /X компилятора см. в разделе /X (Пропуск стандартных путей включения).

Чтобы устранить эту проблему, исправьте путь, используемый компилятором для поиска включаемого или импортируемого файла. Новый проект использует пути поиска по умолчанию. Возможно, потребуется изменить путь поиска включения, чтобы добавить каталог для проекта. При компиляции в командной строке добавьте путь к переменной среды INCLUDE или /I параметр компилятора, чтобы указать путь к файлу.

Чтобы задать путь к каталогу include в Visual Studio, откройте диалоговое окно страниц свойств проекта. Выберите каталоги VC++ в разделе «Свойства конфигурации » в левой области, а затем измените свойство Include Directoryies . Дополнительные сведения о каталогах для отдельных пользователей и проектов, искомых компилятором в Visual Studio, см. на странице свойств каталогов VC++. Дополнительные сведения о параметре /I компилятора см. в разделе /I (Дополнительные каталоги включения).

Среда INCLUDE или LIB командной строки не задана

Если компилятор вызывается из командной строки, для указания путей поиска часто используются переменные среды. Если путь поиска, описанный переменной среды INCLUDE или LIB , неправильно задан, может возникнуть ошибка C1083. Настоятельно рекомендуется использовать ярлык командной строки разработчика, чтобы задать базовую среду для сборок командной строки. Дополнительные сведения см. в разделе «Сборка C/C++ в командной строке». Дополнительные сведения об использовании переменных среды см. в разделе «Практическое руководство. Использование переменных среды в сборке».

Файл может быть заблокирован или использоваться

Если вы используете другую программу для редактирования или доступа к файлу, возможно, файл заблокирован. Попробуйте закрыть файл в другой программе. Иногда другая программа может быть самой Visual Studio, если вы используете параметры параллельной компиляции. Если параметр параллельной сборки отключает ошибку, это проблема. Эта проблема также может быть связана с другими параллельными системами сборки. Будьте внимательны, чтобы задать зависимости файлов и проектов, чтобы порядок сборки был правильным. В некоторых случаях рассмотрите возможность создания промежуточного проекта для принудительного порядка сборки зависимостей для общего файла, который может быть создан несколькими проектами. Иногда антивирусные программы временно блокируют недавно измененные файлы для сканирования. По возможности рекомендуется исключить каталоги сборки проекта из антивирусного сканера.

Включена неправильная версия имени файла

Ошибка C1083 также может указывать на включение неверной версии файла. Например, построение может включать неверную версию файла, содержащего директиву #include для файла заголовка, который не предназначен для данного построения. Например, некоторые файлы могут применяться только к сборкам x86 или к отладочным сборкам. Если файл заголовка не найден, компилятор выдает ошибку C1083. Для исправления этой проблемы необходимо использовать правильный файл, а не добавлять в построение файл заголовка или каталог.

Предкомпилированные заголовки еще не скомпилированы

Если проект настроен на использование предварительно скомпилированных заголовков, необходимо создать соответствующие .pch файлы, чтобы можно было скомпилировать файлы, использующие содержимое заголовка. Например, pch.cpp файл ( stdafx.cpp в Visual Studio 2017 и более ранних версиях) автоматически создается в каталоге проекта для новых проектов. Сначала необходимо скомпилировать этот файл, чтобы создать предкомпилированные файлы заголовков. В стандартной структуре процесса сборки это делается автоматически. Дополнительные сведения см. в разделе «Создание предварительно скомпилированных файлов заголовков».

Дополнительные причины

Вы установили пакет SDK или стороннюю библиотеку, но не открывали новое окно командной строки разработчика после установки пакета SDK или библиотеки. Если пакет SDK или библиотека добавляет файлы в путь INCLUDE , может потребоваться открыть новое окно командной строки разработчика, чтобы получить эти изменения переменной среды.

Файл использует управляемый код, но параметр /clr компилятора не указан. Дополнительные сведения см. в разделе /clr (компиляция среды CLR).

Файл компилируется с помощью другого /analyze параметра параметра компилятора, отличного от используемого для предварительной компиляции заголовков. При предварительной компиляции заголовков проекта все должны использовать одни и те же /analyze параметры. Дополнительные сведения см. в разделе /analyze (Анализ кода).

Файл или каталог был создан подсистема Windows для Linux, включена конфиденциальность регистра для каждого каталога, и указанный случай пути или файла не соответствует регистру пути или файла на диске.

Файл, каталог или диск доступен только для чтения.

Visual Studio или программы командной строки не имеют достаточных разрешений для чтения файла или каталога. Это может произойти, например, если файлы проекта имеют другое право собственности, чем процесс, выполняемый в Visual Studio или программы командной строки. Иногда эту проблему можно устранить, запустив Visual Studio или командную строку разработчика от имени администратора.

Недостаточно дескрипторов файлов. Закройте часть приложений и повторите компиляцию. Эта ситуация маловероятна в обычных условиях. Однако она может возникать при построении крупных проектов на компьютере с ограниченной физической памятью.

Пример

В следующем примере возникает ошибка C1083, если файл «test.h» заголовка не существует в исходном каталоге или в пути поиска включения.

Сведения о сборке проектов C/C++ в интегрированной среде разработки или командной строке, а также о настройке переменных среды см. в разделе «Проекты» и «Системы сборки».

Источник

Error c1083 не удается открыть файл включение stdafx h no such file or directory

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

me all the time that error occurs, look after the forums but not found out what this is about

#include «stdafx.h»
#include
/*
#include

# define CLANOVI_OBITELJI 100
# define MJESECI 100

using namespace std;

int main() <
float dzeparci[CLANOVI_OBITELJI][MJESECI];
float dzeparci_po_clanu[CLANOVI_OBITELJI];
float dzeparci_po_mjesecu[MJESECI];

cout >br_clanova;
cout >br_mjeseci;

float zbroj_dzeparca=0;
for(int i=0; i
zbroj_dzeparca=0;
for(int j=0; j
zbroj_dzeparca += dzeparci[i][j];
>
dzeparci_po_clanu[i] = zbroj_dzeparca/br_mjeseci;
>

for(int i=0; i
zbroj_dzeparca=0;
for(int j=0; j
zbroj_dzeparca += dzeparci[j][i];
>
dzeparci_po_mjesecu[i] = zbroj_dzeparca/br_clanova;
>
cout

Источник

Для новичков про stdafx.h

Precompiled headers предназначены для ускорения сборки проектов. Обычно программисты начинают знакомиться с Visual C++, используя крошечные проекты. На них сложно заметить выигрыш от precompiled headers. Что с ними, что без них, на глаз программа компилируется одинаковое время. Это добавляет путаницы. Человек не видит для себя пользы от этого механизма и решает, что он для специфичных задач и ему никогда не понадобится. И иногда считает так многие годы.

На самом деле, precompiled headers весьма полезная технология. Пользу от него можно заметить, даже если в проекте всего несколько десятков файлов. Особенно выигрыш становится заметен, если используются такие тяжёлые библиотеки как boost.

Если посмотреть *.cpp файлы в проекте, то можно заметить, что во многие включаются одни и те-же наборы заголовочных файлы. Например, , , . В свою очередь, эти файлы включают другие заголовочные файлы и так далее.

Всё это приводит к тому, что препроцессор в компиляторе вновь и вновь выполняет идентичную работу. Он должен читать одни и те же файлы, вставлять их друг в друга, выбирать #ifdef ветки и подставлять значения макросов. Происходит колоссальное дублирование одних и тех же операций.

Можно существенно сократить объем работы, которую должен проделать препроцессор при компиляции проекта. Идея в том, чтобы заранее препроцессировать группу файлов и затем просто подставлять готовый фрагмент текста.

На самом деле, делается ещё ряд шагов. Можно хранить не просто текст, а более обработанную информацию. Я не знаю, как именно устроено в Visual C++. Но, например, можно хранить текст уже разбитый на лексемы. Это ещё больше ускорит процесс компиляции.

Файл, который содержит precompiled headers, имеет расширение «.pch». Имя файла обычно совпадает с названием проекта. Естественно, это и другие используемые имена можно изменить в настройках. Файл может быть весьма большим и зависит от того, как много заголовочных файлов в нём раскрыто. Например, в проекте PVS-Studio он занимает около 3 мегабайт.

Файл *.pch возникает после компиляции stdafx.cpp. Файл собирается с ключом «/Yc». Этот ключ как раз и говорит компилятору, что нужно создать precompiled headers. Файл stdafx.cpp может содержать одну строчку: #include «stdafx.h».

В файле «stdafx.h» находится самое интересное. Сюда нужно включить заголовочные файлы, которые будут заранее препроцессироваться. В качестве примера, вот файл stdafx.h, используемый нами в PVS-Studio (файл сокращён для статьи):

Директивы «#pragma warning» нам нужны, чтобы избавиться от предупреждений, выдаваемых на стандартные библиотеки.

Теперь во все файлы *.c/*.cpp следует включить «stdafx.h». Заодно стоит удалить из этих файлов заголовки, которые уже включаются с помощью «stdafx.h».

А что делать, если используются хотя и похожие, но разные наборы заголовочных файлов? Например, такие:

Файл A: ,
Файл B: ,
Файл C: ,

Нужно делать отдельные precompiled headers? Так сделать можно, но не нужно.

При создании нового проекта Wizard в Visual Studio создаёт два файла: stdafx.h и stdafx.cpp. Именно с помощью них и реализуется механизм precompiled headers.

На самом деле, эти файлы могут называться, как угодно. Важно не название, а параметры компиляции в настройках проекта.

В *.c/*.cpp файле можно использовать только один precompiled header. Однако, в одном проекте может присутствовать несколько разных precompiled headers. Пока будем считать, что он у нас только один.

Итак, если вы воспользовались wizard-ом, то у вас уже есть файлы stdafx.h и stdafx.cpp. Плюс выставлены все необходимые ключи компиляции.

Если в проекте не использовался механизм precompiled headers, то давайте рассмотрим, как его включить. Предлагаю следующую последовательность действий:

Во всех конфигурациях для всех *.c/*.cpp файлов включаем использование precompiled headers. Это делается на вкладке «Precompiled Header»:
1. Выставляем для параметра «Precompiled Header» значение «Use (/Yu)».
2. Для параметра «Precompiled Header File» указываем «stdafx.h».
3. Для параметра «Precompiled Header Output File» указываем «$(IntDir)$(TargetName).pch».
Создаём и добавляем в проект файл stdafx.h. В дальнейшем, в него мы будем включать те заголовочные файлы, которые хотим заранее препроцессировать.
Создаём и добавляем в проект файл stdafx.cpp. В нём одна единственная строка: #include «stdafx.h».
Во всех конфигурациях меняем настройки для файла stdafx.cpp. Выставляем для параметра «Precompiled Header» значение «Create (/Yc)».

Вот мы и включили механизм precompiled headers. Теперь, если мы запустим компиляцию, то будет создан *.pch файл. Однако, затем компиляция остановится из-за ошибок.

Для всех *.c/*.cpp файлов мы указали, что они должны использовать precompiled headers. Этого мало. Теперь в каждый из файлов нужно добавить #include «stdafx.h».

Заголовочный файл «stdafx.h» должен включаться в *.c/*.cpp файл самым первым. Обязательно! Иначе всё равно возникнут ошибки компиляции.

Если подумать, в этом есть логика. Когда файл «stdafx.h» находится в самом начале, то можно подставить уже препроцессированный текст. Этот текст всегда одинаков и ни от чего не зависит.

Представьте ситуацию, если бы мы могли включить до «stdafx.h» ещё какой-то файл. А в этом файле возьмём и напишем: #define bool char. Возникает неоднозначность. Мы меняем содержимое всех файлов, в которых упоминается «bool». Теперь просто так нельзя взять и подставить заранее препроцессированный текст. Ломается весь механизм «precompiled headers». Думаю, это одна из причин, почему «stdafx.h» должен быть расположен в начале. Возможно, есть и другие.

Life hack

Прописывать #include «stdafx.h» во все *.c/*.cpp файлы достаточно утомительно и не интересно. Дополнительно получится ревизия в системе контроля версий, где будет изменено огромное количество файлов. Нехорошо.

Ещё одно неудобство вызывают сторонние библиотеки, включаемые в проект в виде файлов с кодом. Править эти файлы нет смыла. По правильному для них нужно отключить использование «precompiled headers». Однако, если используется несколько мелких сторонних библиотек, это неудобно. Программист постоянно спотыкается об precompiled headers.

Есть вариант, как использовать precompiled headers легко и просто. Способ подойдёт не везде и всегда, но мне он часто помогал.

Можно не прописывать во все файлы #include «stdafx.h», а воспользоваться механизмом «Forced Included File».

Идём на вкладку настроек «Advanced». Выбираем все конфигурации. В поле «Forced Included File» пишем:

Теперь «stdafx.h» автоматически будет включаться в начало ВСЕХ компилируемых файлов. PROFIT!

Больше не потребуется писать #include «stdafx.h» в начале всех *.c/*.cpp файлов. Компилятор сделает это сам.

Что включать в stdafx.h

Это очень важный момент. Бездумное включение в «stdafx.h» всего подряд не только не ускорит компиляцию, но и наоборот замедлит её.

Все файлы, включающие «stdafx.h», зависят от его содержимого. Пусть в «stdafx.h» включен файл «X.h». Если вы поменяете хоть что-то в «X.h», это может повлечь полную перекомпиляцию всего проекта.

Правило. Включайте в «stdafx.h» только те файлы, которые никогда не изменяются или меняются ОЧЕНЬ редко. Хорошими кандидатами являются заголовочные файлы системных и сторонних библиотек.

Если включаете в «stdafx.h» собственные файлы из проекта, соблюдайте двойную бдительность. Включайте только те файлы, которые меняются очень-очень редко.

Если какой-то *.h файл меняется раз в месяц, это уже слишком часто. Как правило, редко удаётся сделать все правки в h-файле с первого раза. Обычно требуется 2-3 итерации. Согласитесь, 2-3 раза полностью перекомпилировать весь проект — занятие неприятное. Плюс полная перекомпиляция потребуется всем вашим коллегам.

Не увлекайтесь с неизменяемыми файлами. Включайте только то, что действительно часто используется. Нет смысла включать , если это нужно только в двух местах. Там, где нужно, там и подключите этот заголовочный файл.

Зачем в одном проекте может понадобиться несколько precompiled headers? Действительно, это нужно не часто. Но приведу пару примеров.

В проекте используются одновременно *.c и *.cpp файлы. Для них нельзя использовать единый *.pch файл. Компилятор выдаст ошибку.

Нужно создать два *.pch файла. Один должен получаться при компилировании C-файла (xx.c), а другой при компилировании C++-файла (yy.cpp). Соответственно, в настройках надо указать, чтобы в С-файлах использовался один precompiled header, а в С++-файлах — другой.

Примечание. Не забудьте указать разные имена для *.pch файлов. Иначе один файл будет перетирать другой.

Другая ситуация. Одна часть проекта использует одну большую библиотеку, а другая часть другую большую библиотеку.

Естественно, не стоит всем участкам кода знать про обе библиотеки. В (неудачных) библиотеках могут пересекаться имена каких-то сущностей.

Логично сделать два precompiled headers и использовать их в разных участках программы. Как уже отмечалось, можно задать произвольные имена файлов, из которых генерируются *.pch файлы. Да и имя *.pch файла тоже можно изменить. Всё это, конечно, требуется делать аккуратно, но ничего сложного в использовании двух precompiled headers нет.

Типовые ошибки при использовании Precompiled Headers

Прочитав внимательно материал выше, вы сможете понять и устранить ошибки, связанные с stdafx.h. Но давайте ещё раз пройдёмся по типовым ошибкам компиляции и разберём их причины. Повторенье — мать ученья.

Fatal error C1083: Cannot open precompiled header file: ‘Debugproject.pch’: No such file or directory

Fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add ‘#include «stdafx.h»’ to your source?

Сообщение говорит само за себя, если его прочитать. Файл компилируется с ключом /Yu. Это значит, что следует использовать precompiled header. Но в файл не включён «stdafx.h».

Нужно вписать в файл #include «stdafx.h».

Если это невозможно, то следует не использовать precompiled header для этого *.c/*.cpp файла. Уберите ключ /Yu.

Fatal error C1853: ‘project.pch’ precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)

В проекте присутствуют как C (*.c), так и C++ (*.cpp) файлы. Для них нельзя использовать единый precompiled header (*.pch файл).

Возможные решения:

Отключить для всех Си-файлов использование precompiled headers. Как показывает практика, *.с файлы препроцессируются в несколько раз быстрее, чем *.cpp файлы. Если *.c файлов не очень много, то, отключив precompiled headers для них, вы ничего не потеряете
Завести два precompiled headers. Первый должен создаваться из stdafx_cpp.cpp, stdafx_cpp.h. Второй из stdafx_c.c, stdafx_c.h. Соответственно, в *.c и *.cpp файлах следует использовать разные precompiled headers. Имена *.pch файлов естественно тоже должны различаться.

Скорее всего, что-то сделано не так. Например, #include «stdafx.h» расположен не в самом начале.

Этот код не скомпилируется. Компилятор выдаст на первый взгляд странное сообщение об ошибке:

Компилятор считает, что все, что указано до строчки #include «stdafx.h» (включительно), является precompiled header. При компиляции файла компилятор заменит все, что до #include «stdafx.h» на текст из *.pch файла. В результате теряется строчка «int A = 10».

Содержимое файла «my.h» не будет использоваться. В результате, нельзя будет использовать функции, объявленные в этом файле. Такое поведение очень сбивает программистов с толку. Они «лечат» его полным отключением precompiled headers и потом рассказывают байки о глючности Visual C++. Запомните, компилятор — это один из наиболее редко глючащих инструментов. В 99.99% случаев надо не злиться на компилятор, а искать ошибку у себя (Proof).

Чтобы таких ситуаций не было, ВСЕГДА пишите #include «stdafx.h» в самом начале файла. Комментарии перед #include «stdafx.h» можно оставить. Они всё равно никак не участвуют в компиляции.

Ещё один вариант — используйте Forced Included File. См. выше раздел «Life hack».

В stdafx.h включён файл, который регулярно редактируется. Или случайно включён автогенерируемый файл.

Внимательно проверьте содержимое файла «stdafx.h». В него должны входить только заголовочные файлы, которые не изменяются или изменяются крайне редко. Учтите, что включённые файлы могут не меняться, но внутри они ссылаются на другие изменяющиеся *.h файлы.

Творится что-то непонятное

Иногда может возникнуть ситуация, что вы поправили код, а ошибка не исчезает. Отладчик показывает непонятные вещи.

Причиной может быть *.pch файл. Как-то так получилось, что компилятор не замечает изменения в одном из заголовочных файлов и не перестраивает *.pch файл. В результате, подставляется старый код. Возможно, это происходило из-за каких-то сбоев, связанных с временем модификации файлов.

Это ОЧЕНЬ редкая ситуация. Но она возможна и про неё надо знать. Я за многие годы программирования сталкивался с ней только 2-3 раза. Помогает полная перекомпиляция проекта.

Это наиболее частая ситуация, с которой к нам обращаются в поддержку. Подробности изложены в документации: «Устранение неисправностей при работе PVS-Studio». Здесь опишу ситуацию кратко.

Если решение (solution) компилируется, это вовсе не значит, что оно правильно устроено. Часто одно решение (solution) содержит множество проектов. В каждом проекте используются свои precompiled headers (имеется свой stdafx.h и stdafx.cpp).

Возникают проблемы, когда начинают использовать файлы из соседнего проекта. Это удобно и так часто делается. Вот только забывают, что в *.cpp файле написано: #include «stdafx.h».

И, какой из stdafx.h подхватится, это интересный вопрос. Но раз программа компилируется — программисту везёт.

К сожалению, нам сложно повторить поведение, которое возникает при использовании *.pch файла. «Честный» препроцессор работает по-другому.

В том, что solution, на самом деле, устроен не верно, можно убедиться, временно отключив precompiled headers. Сразу может вылезти масса интересных ошибок, и программист будет искренне удивляться, каким же чудом компилировался его проект.

За подробностями вновь делаю отсылку к документации. Плюс, если что-то всё равно не ясно, мы подскажем в поддержке.

Заключение

Как вы увидели, ничего сложного в precompiled headers нет. Все «многочисленные глюки компилятора», с которыми сталкивается программист при их использовании, на самом деле, являются непониманием принципов работы. Надеюсь, эта статья поможет устранить непонимание.

Precompiled headers являются очень полезным механизмом, позволяющим существенно увеличить скорость компиляции проектов.

Источник

The specified file name is wrong

The file is not included in the include search path

Third-party library issues and vcpkg

The file is in your project, but not the include search path

The command line INCLUDE or LIB environment is not set

The file may be locked or in use

The wrong version of a file name is included

The precompiled headers are not yet precompiled

Additional causes

Example

See also

Неустранимая ошибка C1083

Указано неверное имя файла

Файл не включен в путь поиска включения

Проблемы со сторонними библиотеками и vcpkg

Файл находится в проекте, но не включает путь поиска

Среда INCLUDE или LIB командной строки не задана

Файл может быть заблокирован или использоваться

Включена неправильная версия имени файла

Предкомпилированные заголовки еще не скомпилированы

Дополнительные причины

Пример

Error c1083 не удается открыть файл включение stdafx h no such file or directory

Answered by:

Question

Для новичков про stdafx.h

Life hack

Что включать в stdafx.h

Типовые ошибки при использовании Precompiled Headers

Fatal error C1083: Cannot open precompiled header file: ‘Debugproject.pch’: No such file or directory

Fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add ‘#include «stdafx.h»’ to your source?

Fatal error C1853: ‘project.pch’ precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)

Творится что-то непонятное

Заключение

Читайте также:

The specified file name is wrong

The file is not included in the include search path

Third-party library issues and vcpkg

The file is in your project, but not the include search path

The command line INCLUDE or LIB environment is not set

The file may be locked or in use

The wrong version of a file name is included

The precompiled headers are not yet precompiled

Additional causes

Example

See also

Неустранимая ошибка C1083

Указано неверное имя файла

Файл не включен в путь поиска включения

Проблемы со сторонними библиотеками и vcpkg

Файл находится в проекте, но не включает путь поиска

Среда INCLUDE или LIB командной строки не задана

Файл может быть заблокирован или использоваться

Включена неправильная версия имени файла

Предкомпилированные заголовки еще не скомпилированы

Дополнительные причины

Пример

Error c1083 не удается открыть файл включение stdafx h no such file or directory

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="https://i1.social.s-msft.com/globalresources/Images/trans.gif" />

Answered by:

Question

Для новичков про stdafx.h

Life hack

Что включать в stdafx.h

Типовые ошибки при использовании Precompiled Headers

Fatal error C1083: Cannot open precompiled header file: ‘Debugproject.pch’: No such file or directory

Fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add ‘#include «stdafx.h»’ to your source?

Fatal error C1853: ‘project.pch’ precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)

Творится что-то непонятное

Заключение

Читайте также: