이 출시되었습니다! 11월의 새로운 기능 및 수정 사항을 읽어보세요.

자주 묻는 질문

IntelliSense가 제대로 작동하게 하려면 어떻게 해야 하나요?

구성 없이 확장은 작업 공간 폴더를 검색하고 컴퓨터에서 찾는 컴파일러를 에뮬레이션하여 헤더를 찾으려고 시도합니다. (예: Windows의 cl.exe/MinGW, macOS/Linux의 gcc/clang). 이 자동 구성이 충분하지 않은 경우, **C/C++: 구성 편집(UI)** 명령을 실행하여 기본값을 수정할 수 있습니다. 해당 보기에서 에뮬레이션하려는 컴파일러, 사용하려는 포함 파일의 경로, 전처리기 정의 등을 변경할 수 있습니다.

또는, 빌드 시스템 확장이 확장과 연동되어 있다면, 해당 확장이 구성을 제공하도록 허용할 수 있습니다. 예를 들어, CMake Tools 확장은 CMake 빌드 시스템을 사용하는 프로젝트를 구성할 수 있습니다. **C/C++: 구성 제공자 변경...** 명령을 사용하여 IntelliSense에 대한 구성을 제공할 수 있도록 해당 확장을 활성화하십시오.

빌드 시스템 확장 지원이 없는 프로젝트에 대한 세 번째 옵션은 빌드 시스템이 이 파일을 생성하는 것을 지원하는 경우 compile_commands.json 파일을 사용하는 것입니다. 구성 UI의 "고급" 섹션에서 compile_commands.json 파일의 경로를 제공하면, 확장은 해당 파일에 나열된 컴파일 정보를 사용하여 IntelliSense를 구성합니다.

참고: 확장이 소스 코드의 `#include` 지시문을 해결할 수 없으면 소스 파일 본문에 대한 린팅 정보가 표시되지 않습니다. VS Code의 **문제** 창을 확인하면, 확장이 찾을 수 없는 파일에 대한 더 많은 정보를 제공합니다. 린팅 정보를 표시하고 싶다면 C_Cpp.errorSquiggles 설정 값을 변경할 수 있습니다.

includePath와 browse.path의 차이점은 무엇인가요?

이 두 가지 설정은 c_cpp_properties.json에서 사용할 수 있으며 혼동될 수 있습니다.

includePath

"기본" IntelliSense 엔진에서 사용하는 경로 문자열 배열로, 의미론적으로 인식하는 IntelliSense 기능을 제공합니다. 포함 경로는 컴파일러에 -I 스위치를 통해 전달하는 경로와 동일합니다. 소스 파일이 파싱될 때, IntelliSense 엔진은 `#include` 지시문에 지정된 파일을 확인하면서 이러한 경로를 앞에 붙여 해결을 시도합니다. 이러한 경로는 /**로 끝나지 않는 한 재귀적으로 검색되지 **않습니다**.

browse.path

전역 심볼 정보를 채우는 "태그 파서"("브라우즈 엔진")에서 사용하는 경로 문자열 배열입니다. 이 엔진은 지정된 경로 아래의 모든 파일을 **재귀적으로** 열거하고 프로젝트 폴더를 태그 파싱하는 동안 잠재적 포함 파일로 추적합니다. 경로의 재귀적 열거를 비활성화하려면 경로 문자열에 /*를 추가할 수 있습니다.

작업 공간을 처음 열 때, 확장은 includePath에 ${workspaceFolder}/**를 추가하고 browse.path는 정의되지 않은 상태로 둡니다 (따라서 includePath로 기본 설정됩니다). 이는 바람직하지 않은 경우, c_cpp_properties.json 파일을 열어 변경할 수 있습니다.

표준 라이브러리 타입에 빨간색 밑줄이 보이는 이유는 무엇인가요?

이것의 가장 일반적인 이유는 포함 경로와 정의가 누락된 경우입니다. 이를 수정하는 가장 쉬운 방법은 **c_cpp_properties.json**에서 compilerPath를 컴파일러 경로로 설정하는 것입니다.

Windows의 MinGW에서 새로운 IntelliSense가 작동하게 하려면 어떻게 해야 하나요?

Visual Studio Code에서 C++ 및 Mingw-w64 시작하기 문서를 참조하세요.

Linux용 Windows 하위 시스템에서 새로운 IntelliSense가 작동하게 하려면 어떻게 해야 하나요?

Visual Studio Code에서 C++ 및 Linux용 Windows 하위 시스템 시작하기 문서를 참조하세요.

포맷 시 파일이 손상되는 이유는 무엇인가요?

작업 공간 폴더가 심볼릭 링크가 있는 경로를 통해 열리면 파일이 손상될 수 있습니다 (이슈 vscode-cpptools#5061). 해결 방법은 심볼릭 링크가 대상에 연결된 경로를 사용하여 작업 공간 폴더를 여는 것입니다.

IntelliSense 데이터베이스를 다시 만들려면 어떻게 해야 하나요?

확장 버전 0.12.3부터 IntelliSense 데이터베이스를 재설정하는 명령이 추가되었습니다. 명령 팔레트(Ctrl+Shift+P)를 열고 **C/C++: IntelliSense 데이터베이스 재설정** 명령을 선택하십시오.

ipch 폴더는 무엇인가요?

언어 서버는 IntelliSense 성능을 향상시키기 위해 포함된 헤더 파일에 대한 정보를 캐싱합니다. 작업 공간 폴더에서 C/C++ 파일을 편집할 때, 언어 서버는 ipch 폴더에 캐시 파일을 저장합니다. 기본적으로 ipch 폴더는 사용자 디렉터리 아래에 저장됩니다. 구체적으로 Windows에서는 %LocalAppData%/Microsoft/vscode-cpptools 아래에, Linux에서는 $XDG_CACHE_HOME/vscode-cpptools/ (또는 XDG_CACHE_HOME이 정의되지 않은 경우 $HOME/.cache/vscode-cpptools/) 아래에, macOS에서는 $HOME/Library/Caches/vscode-cpptools/ 아래에 저장됩니다. 사용자 디렉터리를 기본 경로로 사용함으로써, 확장당 하나의 사용자별 캐시 위치를 생성하게 됩니다. 캐시 크기 제한이 단일 캐시 위치에 적용되므로, 사용자당 하나의 캐시 위치는 기본 설정 값을 사용하는 모든 사용자에 대해 해당 폴더로 캐시의 디스크 공간 사용량을 제한하게 됩니다.

VS Code의 작업 공간별 저장 폴더가 사용되지 않은 이유는 VS Code에서 제공하는 위치가 잘 알려져 있지 않고, 사용자가 보거나 찾기 어려워할 수 있는 GB 단위의 파일을 쓰기를 원하지 않았기 때문입니다.

이 점을 고려하여, 모든 다양한 개발 환경의 요구를 충족시킬 수 없을 것이라는 것을 알았기에, 상황에 가장 적합하게 작동하도록 사용자 지정할 수 있는 설정을 제공했습니다.

"C_Cpp.intelliSenseCachePath": <문자열>

이 설정은 캐시 경로에 대한 작업 공간 또는 전역 재정의를 설정할 수 있게 해줍니다. 예를 들어, 모든 작업 공간 폴더에 대해 단일 캐시 위치를 공유하고 싶다면, VS Code 설정을 열고 **IntelliSense 캐시 경로**에 대한 사용자 설정을 추가하십시오.

"C_Cpp.intelliSenseCacheSize": <숫자>

이 설정은 확장이 수행하는 캐싱 양에 제한을 설정할 수 있게 해줍니다. 이는 근사치이지만, 확장은 설정한 제한에 최대한 가깝게 캐시 크기를 유지하기 위해 최선을 다할 것입니다. 위에서 설명한 대로 작업 공간 간에 캐시 위치를 공유하는 경우에도 제한을 늘리거나 줄일 수 있지만, **IntelliSense 캐시 크기**에 대한 사용자 설정을 추가해야 합니다.

IntelliSense 캐시(ipch)를 비활성화하려면 어떻게 해야 하나요?

IntelliSense 캐싱 기능을 사용하고 싶지 않다면 (예: 캐시가 활성화된 경우에만 발생하는 버그를 해결하기 위해), **IntelliSense 캐시 크기** 설정을 0으로 설정하여 기능을 비활성화할 수 있습니다 (또는 JSON 설정 편집기에서 "C_Cpp.intelliSenseCacheSize": 0"). 캐시 비활성화는 과도한 디스크 쓰기가 발생하는 경우, 특히 헤더를 편집할 때 유용할 수 있습니다.

디버깅을 설정하려면 어떻게 해야 하나요?

디버거는 어떤 실행 파일과 디버거를 사용할지 알 수 있도록 구성해야 합니다.

메인 메뉴에서 **실행** > **구성 추가...**를 선택하십시오.

이제 launch.json 파일이 새 구성으로 편집을 위해 열립니다. 기본 설정은 **아마도** 작동할 것이지만, program 설정을 지정해야 합니다.

디버거 구성 방법에 대한 자세한 내용은 C/C++ 디버깅 구성을 참조하십시오.

디버그 심볼을 활성화하려면 어떻게 해야 하나요?

디버그 심볼 활성화는 사용하는 컴파일러 유형에 따라 다릅니다. 아래는 일부 컴파일러와 디버그 심볼을 활성화하는 데 필요한 컴파일러 옵션입니다.

확실하지 않은 경우, 디버그 심볼을 출력에 포함하는 데 필요한 옵션에 대해 컴파일러 문서를 확인하십시오. 이는 -g 또는 --debug의 변형일 수 있습니다.

Clang (C++)

  • 컴파일러를 수동으로 호출하는 경우, --debug 옵션을 추가하십시오.
  • 스크립트를 사용하는 경우, CXXFLAGS 환경 변수가 설정되어 있는지 확인하십시오. 예를 들어, export CXXFLAGS="${CXXFLAGS} --debug".
  • CMake를 사용하는 경우, CMAKE_CXX_FLAGS가 설정되어 있는지 확인하십시오. 예를 들어, export CMAKE_CXX_FLAGS=${CXXFLAGS}.

Clang (C)

Clang C++와 동일하지만 CXXFLAGS 대신 CFLAGS를 사용하십시오.

gcc 또는 g++

컴파일러를 수동으로 호출하는 경우, -g 옵션을 추가하십시오.

cl.exe

심볼은 *.pdb 파일에 있습니다.

디버깅이 작동하지 않는 이유는 무엇인가요?

중단점이 작동하지 않습니다.

디버깅을 시작할 때 중단점이 바인딩되지 않거나 (실선 빨간색 원) 작동하지 않으면, 컴파일 중에 디버그 심볼을 활성화해야 할 수 있습니다.

디버깅은 시작되지만 스택 트레이스의 모든 줄이 회색입니다.

디버거가 회색 스택 트레이스를 표시하거나, 중단점에서 멈추지 않거나, 호출 스택의 심볼이 회색이면, 실행 파일이 디버그 심볼 없이 컴파일된 것입니다.

C/C++ 확장 문제로 의심될 때 어떻게 해야 하나요?

다른 질문이 있으시면 GitHub 토론 에서 토론을 시작하시거나, 수정해야 할 문제가 발견되면 GitHub 이슈 에 이슈를 제출하십시오.

이슈 보고서의 정보를 기반으로 진단할 수 없는 확장 문제가 발생하는 경우, 디버그 로깅을 활성화하고 로그를 보내달라고 요청할 수 있습니다. C/C++ 확장 로그를 얻는 방법은 C/C++ 확장 로깅을 참조하십시오.

1/17/2023
English 한국어 中文(简体)
© . This site is unofficial and not affiliated with Microsoft.