Visual Studio Code 配置 gcc

時間 2019-11-19

標籤 visual studio code 配置 gcc 欄目 Visual Studio 简体版

原文原文鏈接

做者：譚九鼎
連接：https://www.zhihu.com/question/30315894/answer/154979413
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

0. 前言

本文面向初學者（但不是純小白），分享一點個人經驗。<del>畢竟百度「VS Code C」出來的第一條就是這個網頁</del>如今不是了。其實VS Code真的不太適合寫C，姑且算一種折騰吧。javascript

本文全部內容都可從VS Code的官方文檔：C++ programming with Visual Studio Code 以及各個擴展的文檔中得到，而且他們還會進行更新。（本文也進行過二點五次重大更新）若是你還想了解得更深一點，能夠去看。其實本文基本上是由不斷地嘗試得出來的，若是有錯誤能夠指出。css

個人環境：64位Windows 10。若是你是32位的，在某些地方須要進行修改，不過本文中沒有提，能夠本身試着改。如今的配置在Linux下應該也是可用的。html

1. 環境的準備

VS Code的官網和下載、安裝，我就很少說了。點那個箭頭能夠下到其餘操做系統的版本，如今x64系統下的直接是64位的，不用點箭頭。另外VSC每月都會更新一次（自動下載更新），不要告訴我按照個人配置運行不了最後發現你用的是好幾個月之前的版本。前端

VS Code只是一個編輯器，並非IDE（集成開發環境）。不含編譯器（和許多其它功能），因此編譯器要本身安裝好。若是想用其餘工具鏈或單純用官方擴展，參見第九點。java

其實MinGW和MinGW-w64只是名字像，它們是兩個不一樣的項目。爲了方便，本文中的MinGW指的其實都是MinGW-w64。MinGW自己已經好久沒有更新了，故不推薦。下載如下兩個程序（都要）：c++

LLVM Download Page 在此頁面下載Clang。選Pre-Built Binaries中的Clang for Windows (64-bit)，不須要下.sig文件
MinGW-w64 - for 32 and 64 bit Windows 在此頁面下載MinGW-w64，點那個Download就行

下載好了之後安裝。添加環境變量時：選Add LLVM to the system PATH for all users（即第二項，不過第三項也差很少）。Clang的安裝路徑（Destination folder）我推薦填C:\LLVM，不裝那裏也行，下面的配置里路徑就本身改。安裝完了之後可能會彈出cmd說MSVC integration install failed。這個是由於Clang默認使用的是msvc的工具鏈，而咱們選擇的工具鏈是MinGW，因此就不用管這個提示。若是你想用別的工具鏈，參考第九點。git

MinGW隨便裝哪，Architecture選x86_64，裝好之後把東西所有複製到Clang的文件夾裏去，他們會無衝突合併，效果圖見下。一樣，不作這一步也行，下面的配置里路徑就本身改，還要手動把MinGW的bin文件夾加到path中，由於MinGW不會本身加。至於爲何既要裝Clang又要裝MinGW，是由於Clang沒有頭文件。而後就能夠把MinGW刪了（Uninstall.exe）。不建議安裝多個MinGW，若是你安裝了其餘IDE須要注意把其餘的MinGW從環境變量中去掉；也能夠本身把他們的編譯器設爲Clang。由於幾乎全部的輕量級IDE用的都是MinGW或TDM-GCC，它們不製造編譯器，只是打包了一個。並且它們用在VSC裏也會有奇怪的錯誤。github

若是由於網絡問題一直下載失敗，建議優先本身想辦法（懂個人意思吧？）。實在不行，我提供一個我下好的MinGW（7.2.0版）：https://pan.baidu.com/s/1slwTebVshell

運行cmd，輸clang，應該會提示no input files而不是「不是內部命令或外部命令」或者「沒法將「clang」項識別爲 cmdlet、函數、腳本文件或可運行程序的名稱」。輸clang -v或gcc -v能夠顯示出各自的版本。若是是「不是內部命令或外部命令」，說明clang.exe在的文件夾（個人是C:\LLVM\bin）沒有在環境變量中，要加到path裏才行。怎麼作本身百度。若是加了仍是這樣，重啓。編程

須要安裝的擴展：

C/C++（就是有些教程裏的cpptools）
C/C++ Clang Command Adapter：提供靜態檢測（Lint），很重要
Code Runner：右鍵便可編譯運行單文件，很方便

其餘可選擴展：

Bracket Pair Colorizer：彩虹花括號
Include Autocomplete：提供頭文件名字的補全
C/C++ Snippets：Snippets即重用代碼塊，效果本身百度；這個擴展安裝量雖高，不過我的感受用處實在不大，你也能夠選擇其餘的Snippets擴展甚至本身定義
One Dark Pro：大概是VS Code安裝量最高的主題
vscode-clangd：這個和Adapter二選一，出得比Adapter晚，下載量也低，但倒是llvm官方出的。出現問題時能夠換着試試

不建議/不須要裝的擴展：

GBKtoUTF8：把GBK編碼的文檔轉換成UTF8編碼的。此擴展可能有嚴重的bug，參見第6點，總之不建議裝
C++ Intellisense：用的是gtags，本文第一個版本的選擇。效果很是很是通常。
C/C++ Advanced Lint：即cppflylint，本文第二個版本的選擇。會產生許多奇怪的警告。總之「過期」了
Clang-Format：Adapter包含了此功能

2. 配置四個.json文件

此節我當時大部分參考的是@blackkitty的文章，可是如今修改了不少。

先建立一個你打算存放代碼的文件夾（稱做工做區），路徑不能含有中文和空格和引號。c語言和c++須要創建不一樣的工做區（除非你懂得下面json文件的某些選項，則能夠作到一個工做區使用不一樣的build task）。

打開VS Code，選打開文件夾（不要選「添加工做區文件夾」，理由見上一句），選擇剛纔那個文件夾，點VS Code上的新建文件夾，名稱爲.vscode（這樣作的緣由是Windows的Explorer不容許建立的文件夾第一個字符是點），而後建立 launch.json，tasks.json，settings.json，c_cpp_properties.json放到.vscode文件夾下，效果圖：

複製如下代碼時不要用ie打開本網頁。（不過如今知乎已經徹底不讓ie訪問了）複製出來之後，知乎會自動在前面加上幾行保留全部權利的字，實際使用的時候確定要刪了的。

launch.json代碼：

stopAtEntry可根據本身喜愛修改；cwd能夠控制程序運行時的相對路徑，若有須要能夠改成${fileDirname}（感謝

）。其餘無需更改，除非你不用windows，則能夠用lldb調試（須要本身裝）。type和request不變色是正常現象。

// https://github.com/Microsoft/vscode-cpptools/blob/master/launch.md { "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", // 配置名稱，將會在啓動配置的下拉菜單中顯示 "type": "cppdbg", // 配置類型，這裏只能爲cppdbg "request": "launch", // 請求配置類型，能夠爲launch（啓動）或attach（附加） "program": "${fileDirname}/${fileBasenameNoExtension}.exe", // 將要進行調試的程序的路徑 "args": [], // 程序調試時傳遞給程序的命令行參數，通常設爲空便可 "stopAtEntry": false, // 設爲true時程序將暫停在程序入口處，我通常設置爲true "cwd": "${workspaceFolder}", // 調試程序時的工做目錄 "environment": [], // （環境變量？） "externalConsole": true, // 調試時是否顯示控制檯窗口，通常設置爲true顯示控制檯 "internalConsoleOptions": "neverOpen", // 若是不設爲neverOpen，調試時會跳到「調試控制檯」選項卡，你應該不須要對gdb手動輸命令吧？ "MIMode": "gdb", // 指定鏈接的調試器，能夠爲gdb或lldb。但目前lldb在windows下沒有預編譯好的版本。 "miDebuggerPath": "gdb.exe", // 調試器路徑，Windows下後綴不能省略，Linux下則去掉 "setupCommands": [ // 用處未知，模板如此 { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": false } ], "preLaunchTask": "Compile" // 調試會話開始前執行的任務，通常爲編譯程序。與tasks.json的label相對應 } ] }

tasks.json代碼：

reveal可根據本身喜愛修改，即便設爲never，也只是編譯時不跳轉到「終端」而已，手動點進去仍是能夠看到，我我的設爲never。

命令行參數方面，-std根據本身的須要修改。若是使用Clang編寫C語言，把command的值改爲clang。若是使用MinGW，編譯C用gcc，編譯c++用g++，並把-target和-fcolor那兩條刪去。若是不想要額外警告，把-Wall那一條刪去。參數的做用我加了註釋，還看不懂，百度gcc使用教程。

// https://code.visualstudio.com/docs/editor/tasks { "version": "2.0.0", "tasks": [ { "label": "Compile", // 任務名稱，與launch.json的preLaunchTask相對應 "command": "clang++", // 要使用的編譯器 "args": [ "${file}", "-o", // 指定輸出文件名，不加該參數則默認輸出a.exe，Linux下默認a.out "${fileDirname}/${fileBasenameNoExtension}.exe", "-g", // 生成和調試有關的信息 "-Wall", // 開啓額外警告 "-static-libgcc", // 靜態連接 "-fcolor-diagnostics", // 彩色的錯誤信息？但貌似clang默認開啓而gcc不接受此參數 "--target=x86_64-w64-mingw", // clang的默認target爲msvc，不加這一條就會找不到頭文件；Linux下去掉這一條 "-std=c++17" // C語言最新標準爲c11，或根據本身的須要進行修改 ], // 編譯命令參數 "type": "shell", // 能夠爲shell或process，前者至關於先打開shell再輸入命令，後者是直接運行命令 "group": { "kind": "build", "isDefault": true // 設爲false可作到一個tasks.json配置多個編譯指令，須要本身修改本文件，我這裏很少提 }, "presentation": { "echo": true, "reveal": "always", // 在「終端」中顯示編譯信息的策略，能夠爲always，silent，never。具體參見VSC的文檔 "focus": false, // 設爲true後可使執行task時焦點彙集在終端，但對編譯c和c++來講，設爲true沒有意義 "panel": "shared" // 不一樣的文件的編譯信息共享一個終端面板 } // "problemMatcher":"$gcc" // 若是你不使用clang，去掉前面的註釋符，並在上一條以後加個逗號。照着個人教程作的不須要改（也能夠把這行刪去) } ] }

settings.json代碼：

把這個文件裏的東西放到「用戶設置」裏也能夠覆蓋全局設置，本身進行選擇。

Code Runner的命令行和某些選項能夠根據本身的須要在此處修改，用法仍是參見此擴展的文檔和百度gcc使用教程。

若是你要使用其餘地方的頭文件和庫文件，可能要往clang.cflags和clang.cxxflags里加-I和-L，用法百度gcc使用教程。

clang的補全，在我過去的測試過程當中會讓VSC很是卡，可是如今好像沒有這個問題了。若是你卡，就把clang的補全關掉，用cpptools的（不須要我指明分別是哪兩個吧？）。

Linux下去掉code runner和flags的--target那一條，共四個。

感謝

提到的snippetSuggestions。

{ "files.defaultLanguage": "cpp", // ctrl+N新建文件後默認的語言 "editor.formatOnType": true, // 輸入時就進行格式化，默認觸發字符較少，分號能夠觸發 "editor.snippetSuggestions": "top", // snippets代碼優先顯示補全 "code-runner.runInTerminal": true, // 設置成false會在「輸出」中輸出，沒法輸入 "code-runner.executorMap": { "c": "cd $dir && clang $fileName -o $fileNameWithoutExt.exe -Wall -g -Og -static-libgcc -fcolor-diagnostics --target=x86_64-w64-mingw -std=c11 && $dir$fileNameWithoutExt", "cpp": "cd $dir && clang++ $fileName -o $fileNameWithoutExt.exe -Wall -g -Og -static-libgcc -fcolor-diagnostics --target=x86_64-w64-mingw -std=c++17 && $dir$fileNameWithoutExt" }, // 設置code runner的命令行 "code-runner.saveFileBeforeRun": true, // run code前保存 "code-runner.preserveFocus": true, // 若爲false，run code後光標會聚焦到終端上。若是須要頻繁輸入數據可設爲false "code-runner.clearPreviousOutput": false, // 每次run code前清空屬於code runner的終端消息 "C_Cpp.clang_format_sortIncludes": true, // 格式化時調整include的順序（按字母排序） "C_Cpp.intelliSenseEngine": "Default", // 能夠爲Default或Tag Parser，後者較老，功能較簡單。具體差異參考cpptools擴展文檔 "C_Cpp.errorSquiggles": "Disabled", // 由於有clang的lint，因此關掉 "C_Cpp.autocomplete": "Disabled", // 由於有clang的補全，因此關掉 "clang.cflags": [ // 控制c語言靜態檢測的參數 "--target=x86_64-w64-mingw", "-std=c11", "-Wall" ], "clang.cxxflags": [ // 控制c++靜態檢測時的參數 "--target=x86_64-w64-mingw", "-std=c++17", "-Wall" ], "clang.completion.enable":true // 效果效果比cpptools要好 }

c_cpp_properties.json代碼：

此文件內容來自於Microsoft/vscode-cpptools；這個json不容許有註釋（其實按照標準原本就不能有）。

若是你沒有合併Clang和MinGW，則該文件中的compilerPath必需修改爲MinGW的完整路徑，精確到gcc.exe，不然會提示找不到頭文件；Linux下應該是/usr/bin/gcc。

若是你本身編寫了頭文件又不在workspaceFolder下，路徑也要加到includePath和browse裏。這些路徑是否遞歸有效暫時未知，個人測試是有效的。

Windows下的路徑爲反斜槓，本來應使用兩個反斜槓來轉義，但直接用斜槓在VS Code中也接受。

When you set the compilerPath property and change intelliSenseMode to clang-x64, you no longer need to copy the system include path or defines to includePath, browse.path, or defines to enable IntelliSense to work properly.

{ "configurations": [ { "name": "MinGW", "intelliSenseMode": "clang-x64", "compilerPath": "C:/LLVM/bin/gcc.exe", "includePath": [ "${workspaceFolder}" ], "defines": [], "browse": { "path": [ "${workspaceFolder}" ], "limitSymbolsToIncludedHeaders": true, "databaseFilename": "" }, "cStandard": "c11", "cppStandard": "c++17" } ], "version": 4 }

爲何要往json裏寫這麼多的東西？由於VSC自己並無對C語言特別優待，對其餘許多語言也是這樣。另外稍微提一下，以$開頭的是VSC預約義的變量，具體參見：Variables Reference。

3. 寫代碼，編譯，調試

新建文件後就能夠寫代碼了，c語言源代碼後綴是.c，c++是.cpp或.C（這也要我教嗎……）。代碼文件在保存工做區內均可以（一級目錄或者本身創建文件夾），沒必要放到.vscode文件夾裏，可是仍是前面的話，不要含有中文和空格和引號。按Alt+Shift+F（或者右鍵）能夠格式化代碼。

中止輸入一小段時間（一秒）後就會有Lint，擴展會給一些建議性的warning（好比聲明瞭變量但不使用），本身清楚就行。若是以爲不爽，也有方法不讓它提示，好比去掉-Wall就會少一些。若是還想去掉更多的警告，本身找查怎麼作，我提示一下：-Wno-...。找好參數後加到clang.cflags、clang.cxxflags和tasks.json的args裏。

按ctrl+shift+B單純編譯，按F5爲運行並調試（運行前會自動編譯）；原本ctrl+F5爲運行但不調試，可是在C中貌似沒有用，仍是會調試。在寫程序初期，我強烈建議不要把f5看成編譯來使用，由於有的bug只會產生警告，不會阻止編譯，但這些東西越早期解決越好。編譯信息會在底下的「終端」面板裏，若是代碼有錯誤，點進去能夠看clang報的信息，但由於有Lint了，因此能夠輕鬆不少。

加斷點在列號前面點一下就行，若是想從一開始就停下來，能夠加在main函數那裏，或者launch.json中設置"stopAtEntry": true。按f11能夠一步一步進行，箭頭所指的那行代碼就是下一步要運行的代碼。左邊有個調試欄，能夠看到變量的值,自動欄沒有的能夠手動添加表達式；把鼠標放到變量上能夠看到變量的值，可是隻能識別簡單的表達式；棧幀對於遞歸頗有用；在某些時候還能夠抓取「異常」。

若是你不須要調試，能夠直接右鍵選run code。若是在終端裏運行，能夠輸入數據，可是少了顯示時間的功能；在「輸出」中則上面兩項相反。用它還能夠在非工做區內編譯運行程序，但executorMap記得放到全局設置裏。在終端中按ctrl + C能夠終止程序運行。但它其實只是幫你手動輸命令，功能並不強，算是適用場景不一樣吧。另外，樓下的答主韓駿就是此插件做者，有事通通找他（滑稽）。

另外若是按照個人配置，task和code runner還有一點不一樣的是working directory。前者是你打開的文件夾，後者是文件所在的文件夾。固然它們也均可以本身修改。

若是你想進行少許的多文件編譯，對於c語言請使用clang(gcc)把全部文件編譯成.o的中間代碼，再用clang++(g++)連接.o文件，（爲了方便）並把這些命令寫進批處理中；這個操做門檻很是低，若是不會，百度gcc使用教程。若是你想進行大量的多文件編譯，請學習如何寫makefile或使用cmake，而且修改tasks.json的command和args；這個稍微有一點難度。

若是你用VSC還作別的事（好比寫前端），或者有不止一個工做區，能夠建立一個快捷方式（右鍵新建），把工做區路徑做爲參數傳給VSC主程序，還能夠加個圖標。這操做不難，記得打雙引號就行。如今1.18有了一個窗口多個工做區的功能，「文件」菜單裏也有「保存工做區」這個功能。

某些可能出現的錯誤：

若是你只寫了個hello world，不加任何斷點，按f5之後黑框框一閃而過是正常現象。想讓程序暫停運行能夠在末尾加上一個或兩個getchar();，不明白爲何有時要用兩個？去問大家C語言老師；或用system("pause")，或加斷
若是你要進行調試，不要開優化。gcc用-Og還能夠保留一些調試信息，但clang用了之後就不能用gdb調試了。即便如此我仍是在某一次寫代碼的時候遇到了沒法跳入函數的問題，而VS能夠跳入
重命名文件後，原來已有的Lint還會在問題欄裏；修改了文件後斷點可能會失效。以及還存在一些其餘的像這樣的小bug，通常關掉VSC再開就行
preLaunchTask「Compile」已終止，退出代碼爲 1：編譯有error而且你用的是F5運行的就會有這個提示，有warning是否會觸發不清楚；若是沒有error，點仍然調試就好了；若是有error你還點仍然調試，就會調試上一次編譯成功的文件。有一種緣由是原程序仍在運行，沒法被覆蓋（好比死循環），終端裏報錯爲permission denied，任務管理器結束那個進程便可。但其實全部的編譯失敗都會觸發這個錯誤，出錯的返回值是1難道不是常識？因此僅僅告訴我出現了這個提示根本沒用，由於它的意思就是出錯了，沒有人能看出緣由。這也是爲何我要強烈建議不要把F5看成編譯來使用，按F5出了問題，我根本看不出是編譯期有問題仍是調試期有問題，或是你本身的代碼有問題
沒法打開...，找不到文件(file:///build/glibc-OTsEL5/glibc-2.27/...)：我在Linux下遇到了這個問題，下一個glibc放到指定位置就行，wget http://ftp.gnu.org/gnu/glibc/glibc-2.27.tar.xz，剩下的就不要問我了。或者參見這個：Disable "Unable to open file" during debug · Issue #811 · Microsoft/vscode-cpptools

4. 其餘設置

個人一些其餘的設置，用在全局settings.json裏，根據本身的狀況調整，不須要所有照着個人寫。寫完一個之後要打逗號，最後一個就不用了。

"editor.fontFamily": "等距更紗黑體 SC", // 控制編輯器字體 "workbench.colorTheme": "One Dark Pro", // 主題 "files.trimTrailingWhitespace": true, // 保存時，刪除每一行末尾的空格 "workbench.colorCustomizations": { "activityBar.foreground": "#39C5BB" // 自定義顏色 }, "git.enabled": false, // 若是你不用git，我建議你關閉它 "git.ignoreMissingGitWarning": true, // 同上 "editor.minimap.enabled": false, // 我我的不用minimap，就是右邊那個東西 "editor.dragAndDrop": false, // 選中文字後，能夠拖動它們調整位置。我是不須要 "files.autoGuessEncoding": false, // 啓用後，會在打開文件時嘗試猜想字符集編碼。我關閉的理由見6 "[c]": { // "files.encoding": "gbk" // 這樣的格式能夠對指定後綴的文件應用設置，若是你實在想用gbk，就這樣設置吧。cpp同理。 }

更紗黑體是樓下B神作的字體，特色是標點好看（誤）：be5invis/Sarasa-Gothic

Consolas雖然是Windows自帶字體中還算行的，但它只有英文字體；微軟雅黑雖然是非襯線字體，但它不是等距的，這一點很是不適合編程，等線也不等距；中易宋體……告辭。不下新的字體，其餘兩大系統我不清楚，Windows下簡直沒有編程可用的字體。

5. 進一步學習

學好英語，而後能夠閱讀官方英文文檔：Documentation for Visual Studio Code
快捷鍵：vscode: Visual Studio Code 經常使用快捷鍵
英文文檔中固然有快捷鍵的信息，並且英文文檔會更新。這個單獨列出來仍是給初學者吧。
我就提示一點特別重要的：出現Intellisense或者snippets的時候按tab能夠補全代碼。
VS Code實際上是前端利器，學html, css, javascript時能夠好好利用哦。

6. 關於亂碼

VS Code輸出會出現亂碼，不少人都遇到過。這是由於VS Code內部用的是utf-8編碼，cmd/Powershell是gbk編碼。直接編譯，會把「你好」輸出成「浣犲ソ」。若是把cmd的活動代碼頁改爲65001，會出現漢字只能顯示一半的問題，並且怎麼修改爲UTF8仍是個問題（這個能夠參見樓下

同窗的測試）。Linux就沒有這個問題。若是你只是想在VSC裏運行並且不在別人的WIndows上運行，能夠考慮使用Powershell Core。

本來的解決方法是使用gcc，編譯時用-fexec-charset=GBK這個參數，生成的程序就是GBK編碼的。可是，clang的execution-charset supports only UTF-8。因此，生成的程序在cmd/ps以及VS Code的終端（其實也是powershell）中運行，輸出中文仍是會亂碼；可是在VS Code的「輸出」中就是正常的。若是想解決這個問題，能夠百度「寬字符輸出」，或者本身手動在cmd裏用gcc加上上面那個參數編譯一遍（能夠寫個批處理）。

若是是打開已有的以GBK編碼的文件，VS Code默認會以UTF-8編碼打開（除非你設置了猜想編碼），這樣編輯器內的中文就會亂碼，不過對於初學C的同窗來講，寫的代碼通常只有註釋是中文。此時要點右下角的GBK，選「經過編碼從新打開」，選UTF-8便可。GBKtoUTF8這個擴展，理論上若是VSC檢測出的是GBK編碼的，它就會自動作「以UTF-8格式保存」這個操做；可是若是VSC沒有檢測出是GBK編碼，它就什麼也不會作。可是貌似它有bug，會把當前文件複製一遍插入到光標處……因此不推薦使用

若是你沒有注意到一個GBK編碼的文件被VSC以UTF-8的編碼打開了，又進行了保存，按照個人測試，這文件裏的中文應該是找不回來了。這個仍是比較危險的。並且若是打開了編碼猜想，VSC又猜錯了的話……因此我是關閉編碼自動猜想的。中文特別少的時候猜錯概率很大。

這樣作了之後，在含有中文的路徑下能夠編譯，可是仍然不能調試，因此仍是把代碼放到不含中文的路徑中吧。若是把代碼文件發給其餘用Windows的人，最好轉成gbk，不然別人用記事本打開有可能會亂碼（不過貌似1709改進了記事本的編碼猜想，1803的下一個版本連LF都支持了）。

7. 找不到頭文件的錯誤

有幾位同窗遇到了路徑設置正確，編譯也經過，可是「問題"面板裏出現找不到頭文件的error。我也遇到過。這個error是cpptools報的。可能的解決方法是把你須要的頭文件的路徑加到c_cpp_properties.json中，或者你的compilerPath沒有設置正確。若是仍是解決不了，反正不影響編譯，就當作沒看到算了。若是你遇到了又解決了能夠留言告訴你們。若是是非工做區選c語言或者c++，出現這個錯誤很正常，由於不知足前提：路徑設置正確（沒有c_cpp_properties.json）。

還有一種可能，看評論區BladLust同窗的回覆。

若是是這個錯誤，這是由於clang的默認target爲msvc，須要加--target=x86_64-w64-mingw這個參數才行。這個默認target貌似是寫死在源代碼裏的，反正我找了一圈是沒找到正常修改辦法，下載clang的源代碼，本身改掉，再編譯clang自己，也許能夠解決。或者裝Windows sdk而不使用mingw，這樣就符合默認target了，參考第九點。固然最簡單的辦法就是用gcc。

8. 其餘

按照這樣配置，長期編譯代碼下來確定有一大堆的exe，還可能分散在不一樣的文件夾裏。你能夠考慮修改一下json文件，把生成文件的目錄指定到一個專門放exe的文件夾裏（若是不會，百度gcc使用教程）。或者資源管理器右上角搜索*.exe，就能夠搜出它們。或者寫個bat刪了。都很簡單。
json是一種數據交換格式，大部分是JavaScript的子集，數據冗餘度小。VSC和各個擴展會讀取json中的條目，來決定某些功能的行爲。這麼多條目哪裏來的呢？這其實和API差很少。擴展開發者會把容許修改的選項「告訴」VSC，各個擴展的安裝頁面都有寫，VSC又有intellisense，因此其實很容易寫。若是是單純使用json，我以爲就算曆來沒有見過，邊看邊猜也能寫個大概。又由於擴展開源，你甚至能夠去擴展的github頁面和開發者聊天。
Windows 10，默認輸入法只有一個微軟拼音，按一次shift就能進行中英轉換，而爲了保持兼容，按ctrl加空格也能進行中英轉換，而這個快捷鍵正是強制觸發Intellisense的快捷鍵。因此，我強烈建議手動添加「英語」語言輸入法，寫非前端代碼時切換到純英文輸入法（win+空格）。這樣也能夠解決某些遊戲須要用到shift鍵可是一樣快捷鍵衝突的問題。具體操做我就不說了，本身百度。
VSC是集成git的，不過對於初學者可能並不會用到。我在用某一個版本時，看到git提示我有文件發生了改變。我想消掉這個提示，亂點點了discard changes，而後它就把個人工做區清空了……後來我就把它關了。至於怎麼用git，那又是另外一個話題了，慢慢學吧。
tasks.json中的"problemMatcher":"$gcc"會解析終端中的錯誤提示，由於已經有Clang的Lint了，就不須要這個；若是用了Clang Command Adapter又打開這個，則會出現雙重錯誤提示。原本1.11就說能夠寫$gcc的，但當時其實並不支持，如今早就能用了。不過若是要用非預設版本，就須要本身寫了。
想在自帶的終端裏進行調試？Follow：Use the VSCode debugConsole instead of externalConsole · Issue #35 · Microsoft/vscode-cpptools

9. 其餘工具鏈的選擇

使用MinGW編譯但仍用Clang提供Lint：tasks.json的命令行本身改一改，code runner的命令行在settings.json裏，本身改。這樣能夠在終端中輸出不亂碼，參考第六點。缺點：編譯用的不是Clang，編譯速度相對慢。Lint可能提示的警告不全，好比Clang給出的"did you mean ..."提示，Lint就可能捕獲不到
MinGW-w64 + 官方擴展：不使用Clang。除了上面作的，tasks.json裏problemMatcher打開；settings.json裏的東西本身改一改。缺點：Windows下的Lint效果然的真的不好，Linux稍微好一點。感受相比上一個方案沒有優勢？
Windows SDK + 官方擴展：VS Installer選VC++工具集和一個完整的SDK（默認勾上的那個就是）便可。擴展用cpptools，c_cpp_properties.json能夠自動化配置（ctrl+shift+p, edit configurations）；另外兩個json也要改，VS的編譯器是cl，參數也要改；調試器也許能夠用VS的。不過這樣我以爲也許還不如直接用VS，並且我沒試過
Clang + Windows SDK + C/C++ Clang Command Adapter：這套方案須要修改的東西很少，由於編譯用的仍然是Clang。c_cpp_properties.json仍是能夠自動化配置的；各個地方刪去--target那個參數，由於頭文件用的不是MinGW提供的，默認用的就是MSVC的。VS Installer裏還有一個Clang/c2，根據龔大的文章這個有坑，因此裝官方的版本吧。仍是同上一條，感受不如直接用VS
若是以上都看不懂，能夠試試這個配置好的（不過人家的配置方法和個人不同）：【VSCode】Windows下VSCode便攜式c/c++環境
若是不想用VSC寫了，能夠看看這篇問題：毫無編程基礎的小白準備學習C語言，用VC6仍是VS2015？
codeblocks如今還活着，論壇裏有nightly build，配置一番（雖然一樣有點折騰）也可用。Clion界面美觀，功能應該也挺強，不過只有英文，剛上手用起來可能有點困難，學生能夠免費申請key，不然收費