Подтвердить что ты не робот

Visual Studio 2015 дает мне ошибки при создании простой тестовой консоли

Вот код, который я использую.

#include "stdafx.h"
#include <iostream>

int main() {
    std::cout << "hi";

    return 0;
}

Когда я создаю простое консольное приложение С++ и пытаюсь его создать, возникает эта ошибка:

cannot open include file 'stdio.h': No such file or directory

Почему? Не следует ли включать stdio.h в качестве стандартной библиотеки? Что я могу сделать, чтобы вернуть его?

edit: Я только что просмотрел каталог C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include. Нет stdio.h или stdafx.h. Я действительно не знаю, почему. Как я могу вернуть их?

4b9b3361

ОТВЕТЫ

Ответ 1

Это потому, что Visual Studio изменила путь к заголовкам C.

Там у вас есть информация об этом: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

Что я сделал для решения этой проблемы:

Перейдите к Project->Properties->. В Configuraton Properties->VC++ Diretories->Library Directories добавьте путь к C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\ (выберите свою архитектуру)

И в C/C++->General->Additional include directories добавьте путь к:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt

Примечание. 10.0.10150.0 может отличаться в зависимости от вашей версии.

Ответ 2

У меня была аналогичная проблема с обновлением существующего проекта C от Visual Studio 2013 до VS2017 (я пропустил VS2015); ни один из стандартных заголовков не найден.

Принятый ответ (Cezar Azevedo de Faveri) действительно сработал у меня, но он неэффективен, чтобы просто затмить абсолютный путь в настройках, особенно учитывая, что кто-то может изменить путь установки как Visual Studio, так и SDK; Я бы хотел написать код, который "просто работает", где это возможно.

Итак, я потратил немного времени на изучение того, как VS2017 генерирует новый проект, и в итоге я нашел ответ, который заключается в том, что когда VS2017 обновляет существующий проект C, он забывает обновить одно критическое значение проекта, а это неправильное значение - Версия SDK Windows - не позволяет найти заголовки:

Страницы свойств проекта

По умолчанию VS2017 устанавливает заголовки только для SDK Windows 10 UWP, но не изменяет "версию Windows SDK" в любых проектах, которые он обновляет до версии установленного SDK! После обновления Mine были установлены на "8.1", и для Windows 8.1 не установлены заголовки.

Итак, если вы обновляете существующий проект, вам придется вручную изменить этот параметр на любую версию заголовков, которые у вас есть на самом деле: в моем случае это было явно добавлено 10.0.14393.0 в список (что номер версии для заголовков SDK Windows 10 UWP, которые поставляются с VS2017).

(Список установленных версий можно найти в папке C:\Program Files (x86)\Windows Kits\10\Include и в похожих папках рядом с ним.)

Ответ 3

Я знаю, что я немного опоздал на это, но вместо того, чтобы возиться с настройками пути, в Visual Studio 2017 вы можете

  • щелкните правой кнопкой мыши проект
  • выберите проекты retarget
  • выберите последнюю или любую новую версию SDK Windows и нажмите OK

Это автоматически позаботится обо всех путях и библиотеках include.

Ответ 4

#include "stdafx.h"

Существует известная разница между <...> и "..." включает в себя: вкратце, что первый для библиотеки включает, а второй для локального включает.

Вы упомянули, что искали stdafx.h, но не смогли найти его в установке компилятора. Это говорит о том, что:

  • Вы считаете, что stdafx.h - это файл библиотеки ( не, если только это не MS-специфическое расширение, которое я сомневаюсь, хотя оно традиционно используется как имя файла по умолчанию для прекомпилированного заголовки того же - если вы сделали одно, чего вы почти наверняка не имеете).

  • Из-за 1. вы не создали локальный файл stdafx.h, и поэтому включить эту директиву не удастся. Если это не так, то происходит что-то подозрительное.

Что касается вашей реальной проблемы, у меня есть некоторые примечания:

  • <stdio.h> - это заголовок C, а не С++. Если вы включаете файл С++ (расширение .cpp, возможно, для MSVC), то вы должны использовать заголовок С++ <cstdio>. Однако это не должно фактически вызывать проблемы.

  • Вы все равно не используете stdio (по крайней мере, не напрямую). Вы используете iostream, в который вы входите. Если это включить тот, который вызывает ошибку, то iostream пытается включить его, не может, и ваша установка компилятора будет borked.

  • Попробуйте аналогичную программу:

#include <iostream>
int main() {
    std::cout << "hi" << std::endl;
    return 0;
}

Я только что проверил себя, что это компилируется и выполняется должным образом в Visual Studio 2015 Professional.

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

Ответ 5

Я столкнулся с той же проблемой, и она была решена, когда я запустил vcvarsall.bat, который присутствует в C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC

Ответ 6

Выше предоставляется решение для каждого проекта. Но если вы не хотите переустанавливать VS с нуля или устанавливать каталоги и библиотеки include для каждого решения, вы можете изменить Toolset.props, найденный в:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Платформы\Win32\PlatformToolsets\v140\Toolset.props

  <PropertyGroup>
....................
    <IncludePath Condition="'$(IncludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);**C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt**</IncludePath>
.......................
    <LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86;**C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\**</LibraryPath>
...........................
  </PropertyGroup>

Ответ 7

У меня была эта ошибка на VS2017 после обновления с VS2015. Я попробовал чистую + переустановить и не исправил ошибку. Проблема, которую я обнаружил, была двукратной:

  • $(VC_IncludePath); $(WindowsSDK_IncludePath); не было в пути включения по умолчанию.
  • $(VC_IncludePath); $(WindowsSDK_IncludePath); был фактически ИСКЛЮЧЕН в свойствах по умолчанию (как это произошло?!)

Для исправления новых проектов: Вручную отредактируйте следующие файлы: % LocalAppData%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props % LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props

Убедитесь, что $(VC_IncludePath); $(WindowsSDK_IncludePath); находится в IncludePath и NOT в ExcludePath.

Исправить для старых проектов (которые не просто наследуются от вышеуказанных файлов): Вручную отредактируйте свойства проекта в Обозревателе решений и убедитесь, что $(VC_IncludePath); $(WindowsSDK_IncludePath); находится в IncludePath и NOT в ExcludePath.

Ответ 8

У меня была такая же проблема в Visual Studio Community 2015 после установки текущего SDK Windows, и, как уже писал ранее Signa, это может быть исправлено для всех проектов в файле "Toolset.props" (по крайней мере для VS2015), и я нахожу это самое удобное решение, потому что это нужно делать только один раз. У меня есть несколько примечаний на стороне, потому что есть что-то, на что можно обратить внимание.

Для каждой платформы сборки есть собственный файл "Toolset.props", поэтому оба они должны быть изменены, если вы хотите создать для 32 и 64-битных целей:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140\Toolset.props

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.props

Файлы защищены от записи и вам необходимо удалить защиту записи, прежде чем вы сможете изменить эти файлы (не забудьте вернуть их после завершения).

В настоящее время текущая версия SDK - "10.0.15063.0", и вам нужно настроить ее на версию, которую вы хотите использовать (или на версию SDK, которую вы установили).

Посмотрите на строки IncludePath и LibraryPath в этих файлах реквизита и добавьте следующие пути к ним:

IncludePath: $(программные файлы)\комплекты Windows\10\Include\10.0.15063.0\ucrt

LibraryPath: $(ProgramFiles)\Windows Kits\10\Lib\10.0.15063.0\ucrt\$(PlatformTarget)

Вот пример, как это выглядит для 32-битной версии:

// ... some XML before that ...
<PropertyGroup>
    // ... executable path .....
    <IncludePath Condition="'$(IncludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);$(ProgramFiles)\Windows Kits\10\Include\10.0.15063.0\ucrt;</IncludePath>
    // ... reference path ...
    <LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86;$(ProgramFiles)\Windows Kits\10\Lib\10.0.15063.0\ucrt\$(PlatformTarget);</LibraryPath>
    // ... more XML ...
</PropertyGroup>
// ... even more XML ....

Ответ 9

После повторного запуска аналогичных проблем с VS2017 я более подробно рассмотрел, что вызвало все это. И главная причина заключалась в том, что я все еще использовал модифицированные файлы user.props. Это какое-то время было решением для добавления глобальных включений и путей библиотек ко всем проектам. Но эта функция не рекомендуется Microsoft, и содержимое этих файлов должно быть reset.

Файлы, о которых я говорю, являются файлами user.props в C:\Users\your_name\AppData\Local\Microsoft\MSBuild\v4.0 Для тестирования вы можете просто переименовать (или удалить, если вам нравятся риски), и перезапустить VS. Теперь они создадут для них пустые файлы. И если вы находитесь в Windows 10, то в большинстве случаев этого достаточно, чтобы исправить все ваши проблемы. Даже в старых версиях VS (я тестировал VS2010-VS2017 для более старых версий VS, проблемы, как правило, связаны с ключами реестра и не связаны с этими реквизитами). Windows/VS стала действительно полезной при поиске всех системных библиотек (включая DirectX, которая была основной причиной, по которой мы должны были модифицировать эти файлы в прошлом) и добавив их в правильный порядок включения.

Также предупреждение, как я видел, другие люди говорят об этом. Не изменяйте какой-либо .prop, установленный SDK. Если вам действительно нужно работать с реквизитами, создайте и добавьте свои собственные листы свойств (которые могут перезаписать любые значения по умолчанию) для вашего проекта. И не волнуйтесь, они не будут проверены на исходный контроль, поэтому вы можете распространять свой проект другим.

Если вы все еще на старой версии Windows, это может быть не так просто, как в Windows 10, но я постараюсь дать несколько советов:

То, что вам не хватает для этой конкретной ошибки, - это новый $UniversalCRT_IncludePath. Не нужно жестко указывать этот путь, этот макрос должен содержать правильный. Поэтому добавьте $(UniversalCRT_IncludePath); к IncludePath в вашем собственном свойстве, которое вы добавляете затем в проект.

И для LibraryPath добавьте правильный путь для каждого файла платформы, например $(UniversalCRT_LibraryPath_x64); для .x64. и $(UniversalCRT_LibraryPath_x86); для .Win32.

Что также может быть полезно при попытке исправить это: вы можете узнать значения всех переменных $(MACRO), используемых в системе сборки внутри VisualStudio. Они очень хорошо скрыты: перейдите в свойства - пользовательские шаги сборки - нажмите на командную строку - тогда ничего не набирайте, кроме кнопки "вниз", чтобы получить "редактировать..." - вы нажимаете это - вы получаете диалог, который кнопку "Макросы → ". И это содержит список со всеми значениями макроса.

Ответ 10

Установка обновления Visual Studio 2015 Update 3 решает эту проблему как для новых проектов, так и для существующих проектов, созданных до обновления.

https://www.visualstudio.com/news/releasenotes/vs2015-update3-vs