Visual Studio 2015 daje mi błędy przy tworzeniu prostego programu konsoli testowej.

Question

Oto kod, którego używam.

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

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

    return 0; 
} 

Kiedy utworzyć prostą aplikację konsoli C++ i starają się ją zbudować, ten błąd występuje:

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

Dlaczego? Czy stdio.h nie powinno być dołączone jako standardowa biblioteka? Co mogę zrobić, aby to odzyskać?

edytuj: Właśnie zajrzałem do katalogu C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ VC \ include. Nie ma stdio.h lub stdafx.h. Naprawdę nie jestem pewien dlaczego. Jak mogę je odzyskać?

Answer 1

#include "stdafx.h"

Jest dobrze znane różnica pomiędzy <...> i "..." obejmuje: w skrócie, że pierwsza jest biblioteka zawiera a drugi jest zawiera lokalne.

Wspomniałeś, że szukałeś stdafx.h, ale nie mogłeś go znaleźć w instalacji kompilatora. Sugeruje to, że:

1. Myślisz stdafx.h plik jest biblioteką (nie jest, chyba że to jakiś MS specyficzne rozszerzenie, w co wątpię, chociaż jest tradycyjnie stosowany jako domyślnej nazwy pliku dla prekompilowanych nagłówków przez to samo - jeśli zrobiłeś jeden, który prawie na pewno nie masz).

2. Z powodu 1., nie utworzono lokalnego pliku stdafx.h, a zatem należy zawrzeć w nim dyrektywę o niepowodzeniu. Jeśli nie, to dzieje się coś podejrzanego.

---

Co do rzeczywistego problemu, mam kilka uwag:

1. <stdio.h> jest nagłówek C, C++ nie jeden. Jeśli dołączasz plik C++ (rozszerzenie .cpp, prawdopodobnie dla MSVC), powinieneś użyć nagłówka C++ <cstdio>. Nie powinno to jednak powodować problemu.

2. Nie używasz stdio mimo to (przynajmniej nie bezpośrednio). Korzystasz z iostream, który odpowiednio uwzględniasz. Jeśli to jest to, co powoduje błąd, to iostream próbuje go włączyć, nie może i instalacja twojego kompilatora jest zepsuta.

3. Spróbuj podobny program:

---

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

Właśnie sprawdzone sobie, że to kompiluje i wykonuje poprawnie pod Visual Studio 2015 Professional.

Jeśli ten program wykonuje kompilację , nie, sugeruję ponowną instalację programu Visual Studio.Z mojego doświadczenia wynika, że ​​często rozwiązuje to trudne problemy z konfiguracją.

Answer 2

To dlatego, że Visual studio zmieniło ścieżkę do nagłówków C.

Nie masz info o tym: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

co zrobiłem, aby rozwiązać to:

idź do Project->Properties->. W Configuraton Properties->VC++ Diretories->Library Directories dodać ścieżkę do C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\(Wybierz architekturę)

I C/C++->General->Additional include directories dodać ścieżkę do:

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

Uwaga: 10.0.10150.0 mogą się różnić w zależności od wersji.

Answer 3

I w obliczu tego samego problemu, kiedy to został rozwiązany Pobiegłem vcvarsall.bat, która jest obecna w C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ VC

Answer 4

Instalacja wizualna Studio 2015 Update 3 rozwiązuje ten problem zarówno w przypadku nowych projektów, jak i istniejących projektów utworzonych przed aktualizacją.

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

Answer 5

Przede dostarcza rozwiązanie dla każdego projektu. Ale jeśli nie chcesz, aby ponownie zainstalować VS od podstaw lub ustaw obejmują katalogów i bibliotek na każde rozwiązanie, które można modyfikować Toolset.props znaleźć w:

C: Program Files \ (x86) \ MSBuild \ Microsoft .cpp \ v4.0 \ V140 \ platform \ 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> 

Answer 6

wiem, że jestem trochę późno na to, ale zamiast bawić z ustawieniami ścieżki, w Visual Studio 2017 ty może

• kliknij prawym przyciskiem myszy projekt
• wybrać ponownie kierować projekty
• wybrać ostatni lub każda nowa wersja Windows SDK i kliknij OK

Spowoduje to automatyczne zadbać o wszystkie zawierają ścieżek i bibliotek.

Answer 7

Miałem podobny problem z uaktualnieniem istniejącego projektu C z Visual Studio 2013 do VS2017 (pominąłem VS2015); nie znaleziono tam również żadnych standardowych nagłówków.

Zaakceptowana odpowiedź (napisana przez Cezara Azevedo de Faveri) zadziałała u mnie, ale jest to nieuporządkowane, aby zacinać absolutną ścieżkę w ustawieniach, szczególnie biorąc pod uwagę, że ktoś może zmienić ścieżkę instalacji zarówno Visual Studio, jak i SDK; Chciałbym napisać kod, który "po prostu działa" tam, gdzie to możliwe.

Spędziłem więc trochę czasu, badając, jak VS2017 generuje nowy projekt, i ostatecznie znalazłem odpowiedź, która oznacza, że ​​gdy VS2017 uaktualnia istniejący projekt C, zapomina o aktualizacji jednej krytycznej wartości projektu i tej niepoprawnej wartości - SDK w wersji Windows - sprawia, że ​​nagłówki nie mogąc znaleźć:

domyślnie VS2017 instaluje nagłówki tylko dla Windows 10 UWP SDK, ale to nie zmienia „Windows SDK w wersji” wszelkie projekty uaktualnione do wersji pakietu SDK, która została faktycznie zainstalowana! Moje kopie zostały ustawione na "8.1" po aktualizacji i nie ma zainstalowanych nagłówków dla Windows 8.1

Więc jeśli aktualizujesz istniejący projekt, będziesz musiał ręcznie zmienić to ustawienie na dowolną wersję nagłówków Faktycznie: w moim przypadku było to jednoznaczne dodanie do listy 10.0.14393.0 (jest to numer wersji dla nagłówków Windows 10 UWP SDK dostarczanych z VS2017).

(lista zainstalowanych wersji można znaleźć w folderze C:\Program Files (x86)\Windows Kits\10\Include, aw podobnej foldery obok niego).

Answer 8

miałem ten błąd na VS2017 po uaktualnieniu z VS2015. Próbowałem wyczyścić + ponownie i nie naprawił błędu. Problem, który znalazłem, był podwójny:

1. $ (VC_IncludePath); $ (WindowsSDK_IncludePath); nie znajduje się w domyślnej ścieżce dołączania.
2. $ (VC_IncludePath); $ (WindowsSDK_IncludePath); faktycznie wykluczyć właściwości domyślnych (jak to się stało ?!)

naprawić nowych projektach: ręcznie edytować pliki: % LocalAppData% \ Microsoft \ MSBuild \ v4.0 \ Microsoft.Cpp .Win32.user.props % LocalAppData% \ Microsoft \ MSBuild \ v4.0 \ Microsoft.Cpp.x64.user.props

Upewnij się, że $ (VC_IncludePath); $ (WindowsSDK_IncludePath); znajduje się w IncludePath, a NOT w ExcludePath.

Aby naprawić stare projekty (które nie tylko dziedziczą z powyższych plików): Ręcznie edytuj właściwości projektu w Eksploratorze rozwiązań i upewnij się, że $ (VC_IncludePath); $ (WindowsSDK_IncludePath); znajduje się w IncludePath, a NOT w ExcludePath.

Answer 9

Miałem ten sam problem w Visual Studio Community 2015 po zainstalowaniu aktualnego zestawu Windows SDK i jak Signa już pisał wcześniej, można to naprawić dla wszystkich projektów w pliku "Toolset.props" (przynajmniej dla VS2015) i uważam to za najwygodniejsze rozwiązanie, ponieważ trzeba to zrobić tylko raz. Mam kilka uwag bocznych, ponieważ jest na co zwrócić uwagę.

dla każdej platformy budowlanej istnieje własny „Toolset.props” plik, więc oba muszą być modyfikowane, jeśli chcesz zbudować dla 32 i 64 bitowych celów:

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 

Pliki są zapisem -chroniony i musisz usunąć ochronę przed zapisem, zanim będziesz mógł zmienić te pliki (pamiętaj, aby ponownie je założyć po zakończeniu).

Obecnie aktualna wersja pakietu SDK to "10.0.15063.0 "i musisz dostosować to do wersji, której chcesz użyć (lub do wersji SDK, którą zainstalowałeś)

Zwróć uwagę na linie IncludePath i LibraryPath w tych plikach rekwizytów i dodaj następujące ścieżki do nich :

IncludePath: $ (ProgramFiles) \ Windows Kits \ 10 \ Include \ 10.0.15063.0 \ ucrt

LibraryPath: $ (ProgramFiles) \ Windows Kits \ 10 \ Lib \ 10.0. 15063.0 \ ucrt \ $ (PlatformTarget)

Oto próbka, jak to wygląda w przypadku wersji 32-bitowej:

// ... 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 .... 

Answer 10

Po uruchomieniu w podobnych problemów po raz kolejny z VS2017 Wziąłem bliżej przyjrzeć się, co było przyczyną tego wszystkiego. Głównym powodem było to, że wciąż używałem zmodyfikowanych plików user.props. Które było przez jakiś czas rozwiązaniem dodawania globalnych ścieżek dostępu i bibliotek do wszystkich projektów. Ta funkcja jest jednak przestarzała przez firmę Microsoft, a zawartość tych plików powinna zostać zresetowana.

Pliki, o których mówię, to pliki user.props w C: \ Users \ twoja_nazwa \ AppData \ Local \ Microsoft \ MSBuild \ v4.0 Do testowania możesz po prostu zmienić nazwę (lub usunąć, jeśli lubisz ryzyko) je i uruchom ponownie VS. Stworzy teraz puste pliki dla tych osób. A jeśli korzystasz z systemu Windows 10, w większości przypadków wystarczy, aby rozwiązać wszystkie problemy. Nawet w starszych wersjach VS (testowałem z VS2010-VS2017, nawet w starszych wersjach VS problemy zazwyczaj dotyczą kluczy rejestru i nie zawierają plików rekwizytów). Windows/VS stał się teraz naprawdę dobry w znajdowaniu wszystkich bibliotek systemowych (w tym DirectX, który był głównym powodem, dla którego musieliśmy zmodyfikować te pliki w przeszłości) i dodaniu ich do właściwej kolejności włączania.

Ostrzegam także, że widziałem, jak polecają to inne osoby. Wykonaj , a nie zmień dowolny plik .prop zainstalowany przez SDK. Jeśli naprawdę potrzebujesz pracować z rekwizytami, stwórz i dodaj własne arkusze właściwości (które mogą nadpisać wszelkie wartości domyślne) do twojego projektu. I nie martw się, nie będą one kontrolowane przez źródło, więc nadal będziesz mógł rozpowszechniać swój projekt na innych.

Jeśli nadal na starszym systemie Windows może nie być tak proste, jak w systemie Windows 10, ale postaram się podać kilka wskazówek:

Czego brakuje w tym betonowym błędu jest nowa $ UniversalCRT_IncludePath . Nie ma potrzeby, aby kodować tę ścieżkę, to makro powinno zawierać poprawną. Więc dodaj $ (UniversalCRT_IncludePath); do IncludePath we własnej nieruchomości, którą dodajesz do projektu.

A dla LibraryPath dodaj poprawną ścieżkę na plik platformy, np. $ (UniversalCRT_LibraryPath_x64); dla .x64. i $ (UniversalCRT_LibraryPath_x86); dla .Win32.

Co może być przydatne, gdy próbujemy to naprawić: Możesz dowiedzieć się wartości wszystkich zmiennych $ (MAKRO) używanych w systemie kompilacji wewnątrz VisualStudio. Są po prostu bardzo dobrze ukryte: Przejdź do właściwości - niestandardowe kroki kompilacji - kliknij w wierszu poleceń - wtedy nie wpisuj niczego, ale kliknij przycisk w dół, aby uzyskać "edytuj ..." - kliknij to - pojawi się okno dialogowe, które ma przycisk "Makra >>". I że zawiera listę wszystkich wartości makr.