잠재적인 업그레이드 문제 개요(Visual C++)

지난 몇 년 동안 C++ 언어 자체, C++ 표준 라이브러리, C 런타임(CRT) 및 MFC, ATL 등의 기타 라이브러리의 변경과 함께 Visual C++ 컴파일러에서 많은 변화가 있었습니다. 결과적으로, 이전 버전의 Visual C++에서 응용 프로그램을 업그레이드할 때 이전에는 정상적으로 컴파일된 코드에서 컴파일러 및 링커 오류와 경고가 발생할 수 있습니다. 원래 코드베이스가 오래될수록 이러한 오류 가능성이 커집니다. 이 개요에서는 발생할 수 있는 가장 일반적인 문제 클래스를 요약하고 자세한 정보 링크를 제공합니다.

참고: 과거에는 여러 버전의 Visual Studio에 걸친 업그레이드를 한 번에 하나씩 증분 방식으로 수행하도록 권장했습니다. 이 방법은 더 이상 권장되지 않습니다. 코드베이스가 아무리 오래되었다 해도 최신 버전의 Visual Studio로 업그레이드하는 것이 더 간단한 경우가 많았습니다.

업그레이드 프로세스와 관련된 질문이나 의견이 있으면 Microsoft의 vcupgrade로 보내주시기 바랍니다.

라이브러리 및 도구 집합 종속성

응용 프로그램을 새 버전의 Visual C++ 컴파일러로 업그레이드하는 경우 응용 프로그램이 연결하는 모든 라이브러리와 DLL도 업그레이드하는 것이 좋으며, 대부분의 경우 이 작업이 필요합니다. 이렇게 하려면 소스 코드에 액세스할 수 있거나, 라이브러리 공급업체가 동일한 주 버전을 사용하여 컴파일된 새 이진 파일을 제공할 수 있어야 합니다. 이러한 조건 중 하나에 해당하면 이진 호환성의 세부 사항을 처리하는 이 섹션을 건너뛰어도 됩니다. 이러한 조건에 해당하지 않는 경우 업그레이드된 응용 프로그램에서 라이브러리를 사용하지 못할 수 있습니다. 이 섹션의 정보는 업그레이드를 진행할 수 있는지 여부를 이해하는 데 도움이 됩니다.

도구 집합

obj 및 lib 파일 형식은 잘 정의되어 있고 거의 변경되지 않습니다. 때때로 이러한 파일 형식이 추가되지만, 일반적으로 이러한 추가 항목은 최신 도구 집합이 이전 도구 집합에서 생성된 개체 파일 및 라이브러리를 사용하는 데 영향을 주지 않습니다. 여기서 한 가지 중요한 예외는 /GL(링크 타임 코드 생성/전체 프로그램 최적화)을 사용하여 컴파일하는 경우입니다. /GL을 사용하여 컴파일하는 경우 결과로 생성된 개체 파일은 이 파일을 생성하는 데 사용된 것과 동일한 도구 집합을 통해서만 연결할 수 있습니다. 따라서 /GL 및 Visual Studio 2017(v141) 컴파일러를 사용하여 개체 파일을 생성하는 경우 Visual Studio 2017(v141) 링커를 사용하여 연결해야 합니다. 이는 /GL 개체 내의 내부 데이터 구조가 도구 집합의 주 버전 간에 안정적이지 않으며 최신 도구 집합이 오래된 데이터 형식을 이해하지 못하기 때문입니다.

C++에는 안정적인 ABI(응용 프로그램 이진 인터페이스)가 없습니다. Visual C++는 릴리스의 모든 부 버전에 대해 안정적인 ABI를 유지 관리합니다. 예를 들어 Visual Studio 2017과 모든 업데이트는 이진 호환됩니다. 그러나 Visual C++의 주 버전 간에는 ABI가 호환되지 않을 수 있습니다(단, 2015와 2017은 이진 호환됨). 즉, C++ 형식 레이아웃, 이름 데코레이션, 예외 처리 및 C++ ABI의 다른 부분에서 주요 변경이 수행될 수 있습니다. 따라서 C++ 연결이 있는 외부 기호를 포함하는 개체 파일은 다른 주 버전의 Visual C++ 도구 집합을 사용하여 생성된 개체 파일에 제대로 연결하지 못할 수 있습니다. 여기서 "작동하지 않을 수 있다"는 말은 여러 가능한 결과를 나타냅니다. 즉, 연결에 완전히 실패하거나(예: 이름 데코레이션이 변경된 경우), 연결은 성공하지만 런타임 시 기능이 작동하지 않거나(예: 형식 레이아웃이 변경된 경우), 대부분의 경우 기능이 작동하고 오류가 발생하지 않을 수도 있습니다. 또한 C++ ABI는 불안정하지만 C ABI 및 COM에 필요한 C++ ABI의 하위 집합은 안정적입니다.

라이브러리

특정 버전의 Visual C++ 라이브러리 헤더를 사용하여 소스 파일을 컴파일하는 경우(헤더 #including 사용) 결과로 생성된 개체 파일은 동일한 버전의 Visual C++ 라이브러리에만 연결해야 합니다. 따라서, 예를 들어 소스 파일이 Visual Studio 2017 <immintrin.h>를 사용하여 컴파일된 경우 Visual Studio 2017 vcruntime 라이브러리에 연결해야 합니다. 마찬가지로, 소스 파일이 Visual Studio 2017 <iostream>을 사용하여 컴파일된 경우 Visual Studio 2017 표준 C++ 라이브러리인 msvcprt에 연결해야 합니다. 혼합 및 일치는 지원되지 않습니다.

C++ 표준 라이브러리의 경우 Visual Studio 2010 이후 표준 헤더에서 #pragma detect_mismatch를 사용하여 혼합 및 일치가 명시적으로 금지되었습니다. 호환되지 않는 개체 파일이나 잘못된 표준 라이브러리에 연결을 시도하면 연결이 실패합니다.

CRT의 경우 혼합 및 일치가 지원된 적이 없지만, API 화면이 많이 변경되지 않았기 때문에 Visual Studio 2015 및 유니버설 CRT까지 작동하는 경우가 많았습니다. 앞으로 이전 버전과의 호환성을 유지할 수 있도록 유니버설 CRT에서는 이전 버전과의 호환성을 중단했습니다. 즉, 앞으로는 버전이 있는 새 유니버설 CRT 이진을 도입할 계획이 없습니다. 대신, 기존 유니버설 CRT가 현재 위치에서 업데이트됩니다.

이전 버전의 Microsoft C 런타임 헤더를 사용하여 컴파일된 개체 파일(및 라이브러리)과 부분 링크 호환성을 제공하기 위해 Visual Studio 2015 이상에서는 legacy_stdio_definitions.lib 라이브러리가 제공됩니다. 이 라이브러리는 유니버설 CRT에서 제거된 대부분의 함수 및 데이터 내보내기에 대해 호환성 기호를 제공합니다. legacy_stdio_definitions.lib에서 제공하는 호환성 기호 집합은 Windows SDK에 포함된 라이브러리의 모든 종속성을 포함하여 대부분의 종속성을 충족하기에 충분합니다. 그러나 다음과 같이 유니버설 CRT에서 제거되었으며 호환성 기호를 제공할 수 없는 몇 가지 기호도 있습니다. 이러한 기호로 일부 함수(예: _iob_func)와 데이터 내보내기(예: __imp\_iob, __imp\_pctype, __imp\__mb_cur_max)가 있습니다.

이전 버전의 C 런타임 헤더를 사용하여 빌드된 정적 라이브러리가 있는 경우 다음 작업을 이 순서대로 수행하는 것이 좋습니다.

  1. 유니버설 CRT에 연결할 수 있도록 Visual C++ 2017 및 유니버설 CRT 헤더를 사용하여 정적 라이브러리를 다시 빌드합니다. 이는 완벽하게 지원되는 최상의 옵션입니다.

  2. 정적 라이브러리를 다시 빌드할 수 없거나 다시 빌드하지 않으려는 경우 legacy_stdio_definitions.lib에 연결을 시도할 수 있습니다. 정적 라이브러리의 링크 타임 종속성을 충족하는 경우 이진에서 사용 시 정적 라이브러리를 철저히 테스트하여 유니버설 CRT에 대한 동작 변경 내용의 영향을 받지 않는지 확인하는 것이 좋습니다.

  3. legacy_stdio_definitions.lib가 정적 라이브러리의 종속성을 충족하지 않거나 앞에서 언급한 동작 변경 내용으로 인해 라이브러리가 유니버설 CRT에서 작동하지 않는 경우 정적 라이브러리를 DLL로 캡슐화하고 이 DLL을 올바른 버전의 Microsoft C 런타임에 연결하는 것이 좋습니다. 예를 들어 정적 라이브러리가 Visual C++ 2013을 사용하여 빌드된 경우 Visual C++ 2013과 Visual C++ 2013 라이브러리를 사용하여 이 DLL을 빌드하는 것이 좋습니다. 라이브러리를 DLL로 빌드하면 특정 버전의 Microsoft C 런타임에 종속성이 있는 구현 세부 정보가 캡슐화됩니다. DLL 경계를 넘어 FILE*을 반환하는 경우나 malloc 할당된 포인터를 반환하고 호출자가 해제할 것으로 기대하는 경우와 같이 DLL 인터페이스에서 사용하는 C 런타임의 세부 정보가 누출되지 않도록 주의하세요.

    단일 프로세스에서 여러 CRT를 사용하는 것 자체는 문제가 없습니다. 실제로 대부분의 프로세스는 여러 CRT DLL을 로드하게 됩니다. 예를 들어 Windows 운영 체제 구성 요소는 msvcrt.dll을 사용하고 CLR은 고유한 개인 CRT를 사용합니다. 여러 CRT의 상태를 혼합하면 문제가 발생합니다. 예를 들어 msvcr110.dll!malloc를 사용하여 메모리를 할당하고 msvcr120.dll!free를 사용하여 해당 메모리 할당을 취소해서는 안 되며, msvcr110!fopen을 사용하여 FILE을 열고 msvcr120!fread을 사용하여 해당 FILE에서 읽기를 시도하면 안 됩니다. 여러 CRT의 상태를 혼합하지 않는 한 단일 프로세스에서 여러 CRT를 안전하게 로드할 수 있습니다.

    자세한 내용은 코드를 유니버설 CRT로 업그레이드을 참조하세요.

프로젝트 설정으로 인한 오류

업그레이드 프로세스를 시작하려면 최신 버전의 Visual Studio에서 이전 프로젝트/솔루션/작업 영역을 열면 됩니다. Visual Studio는 이전 프로젝트 설정에 따라 새 프로젝트를 만듭니다. 이전 프로젝트에 비표준 위치로 하드 코드된 라이브러리 또는 포함 경로가 있는 경우 프로젝트에서 기본 설정을 사용할 때 해당 경로의 파일이 컴파일러에 표시되지 않을 수 있습니다. 자세한 내용은 링커 OutputFile 설정을 참조하세요.

일반적으로, 프로젝트 유지 관리를 간소화하고 업그레이드된 코드가 최대한 빨리 컴파일되도록 돕기 위해 지금 프로젝트 코드를 제대로 구성하는 것이 좋습니다. 소스 코드가 이미 잘 구성되었으며 이전 프로젝트가 Visual Studio 2010 이상으로 컴파일된 경우 이전 컴파일러와 새 컴파일러 둘 다에서 컴파일을 지원하도록 새 프로젝트 파일을 수동으로 편집할 수 있습니다. 다음 예제에서는 Visual Studio 2015와 Visual Studio 2017 둘 다에 대해 컴파일하는 방법을 보여 줍니다.

<PlatformToolset Condition="'$(VisualStudioVersion)'=='14.0'">v140</PlatformToolset>  
<PlatformToolset Condition="'$(VisualStudioVersion)'=='15.0'">v141</PlatformToolset>   

LNK2019: 확인할 수 없는 외부 참조

확인할 수 없는 기호의 경우 프로젝트 설정을 수정해야 할 수 있습니다.

  • 소스 파일이 기본이 아닌 위치에 있는 경우 프로젝트의 Include 디렉터리에 대한 경로를 추가했나요?

  • 외부 참조가 .lib 파일에서 정의된 경우 프로젝트 속성에서 lib 경로를 지정했으며 실제로 해당 위치에 올바른 버전의 .lib 파일이 있나요?

  • 다른 버전의 Visual Studio를 사용하여 컴파일된 .lib 파일에 연결하려고 하나요? 그렇다면 라이브러리 및 도구 집합 종속성에 대한 이전 섹션을 참조하세요.

  • 호출 사이트의 인수 형식이 함수의 기존 오버로드와 실제로 일치하나요? 함수의 시그니처와 해당 함수를 호출하는 코드에서 typedef의 기본 형식이 예상과 같은지 확인합니다.

    확인되지 않은 기호 오류를 해결하려면 dumpbin.exe를 사용하여 이진 파일에 정의된 기호를 검사해 볼 수 있습니다. 다음 명령줄을 실행하여 라이브러리에 정의된 기호를 확인해 보세요.

dumpbin.exe /LINKERMEMBER somelibrary.lib  

/Zc:wchar_t(wchar_t를 네이티브 형식으로 인식)

Visual C++ 6.0 및 이전 버전에서는 wchar_t가 기본 제공 형식으로 구현되지 않고 wchar.h에서 unsigned short에 대한 typedef로 선언되었습니다. C++ 표준에서는 wchar_t가 기본 제공 형식이어야 합니다. typedef 버전을 사용하면 이식성 문제가 발생할 수 있습니다. 이전 버전의 Visual C++에서 업그레이드하고 코드가 wchar_t를 unsigned short로 암시적으로 변환하려 하기 때문에 컴파일러 오류 C2664가 발생하는 경우 /Zc:wchar_t-를 설정하는 대신 오류를 수정하기 위해 코드를 변경하는 것이 좋습니다. 자세한 내용은 /Zc:wchar_t(wchar_t는 네이티브 형식임)를 참조하세요.

/NODEFAULTLIB, /ENTRY 및 /NOENTRY 링커 옵션을 사용하여 업그레이드

/NODEFAULTLIB 링커 옵션(또는 모든 기본 라이브러리 무시 링커 속성)은 CRT 등의 기본 라이브러리를 자동으로 연결하지 않도록 링커에 지시합니다. 즉, 각 라이브러리가 개별 입력으로 나타나야 합니다. 이 라이브러리 목록은 프로젝트 속성의 링커 섹션에 있는 추가 종속성 속성에 제공됩니다.

일부 기본 라이브러리의 이름이 변경되었기 때문에 이 옵션을 사용하는 프로젝트는 업그레이드 시 문제가 발생합니다. 추가 종속성 속성이나 링커 명령줄에 각 라이브러리가 나열되어야 하므로 현재 이름을 사용하도록 라이브러리 목록을 업데이트해야 합니다.

다음 표에서는 Visual Studio 2015부터 이름이 변경된 라이브러리를 보여 줍니다. 업그레이드하려면 첫 번째 열의 이름을 두 번째 열의 이름으로 바꾸어야 합니다. 이러한 라이브러리 중 일부는 가져오기 라이브러리이지만 문제가 되지 않습니다.

기존 이름 새 이름
libcmt.lib libucrt.lib, libvcruntime.lib
libcmtd.lib libucrtd.lib, libvcruntimed.lib
msvcrt.lib ucrt.lib, vcruntime.lib
msvcrtd.lib ucrtd.lib, vcruntimed.lib

기본 라이브러리를 건너뛰는 효과가 있는 /ENTRY 옵션 또는 /NOENTRY 옵션을 사용하는 경우에도 같은 문제가 적용됩니다.

향상된 언어 규칙으로 인한 오류

Visual C++ 컴파일러는 지난 몇 년 동안 C++ 표준 준수를 지속적으로 개선해 왔습니다. 이전 버전의 Visual C++에서 컴파일된 코드가 Visual Studio 2017에서는 컴파일되지 않을 수 있습니다. 컴파일러가 이전에 무시되었거나 명시적으로 허용된 오류에 올바르게 플래그를 지정하기 때문입니다.

예를 들어 /Zc:forScope 스위치는 Visual C++의 초기에 도입되었습니다. 루프 변수에 대해 비준수 동작을 허용합니다. 해당 스위치는 이제 사용되지 않으며 이후 버전에서 제거될 수 있습니다. 코드를 업그레이드하는 경우 해당 스위치를 사용하지 않는 것이 좋습니다. 자세한 내용은 /Zc:forScope-가 사용되지 않음을 참조하세요.

업그레이드할 때 표시될 수 있는 일반적인 컴파일러 오류 중 한 가지 예는 비 const 인수가 const 매개 변수에 전달되는 경우입니다. 이전 버전의 Visual C++에서는 때때로 이러한 경우에 오류 플래그가 지정되지 않았습니다. 자세한 내용은 컴파일러의 보다 엄격한 변환을 참조하세요.

특정 규칙 향상에 대한 자세한 내용은 Visual C++ 변경 기록 2003 – 2015Visual Studio 2017의 C++ 규칙 향상을 참조하세요.

<stdint.h> 정수 계열 형식과 관련된 오류

<stdint.h> 헤더는 기본 제공 정수 계열 형식과 달리 모든 플랫폼에서 지정된 길이를 유지하는 typedef 및 매크로를 정의합니다. 몇 가지 예로 uint32_t와 int64_t가 있습니다. Visual Studio 2010의 Visual C++에서는 <stdint.h>가 추가되었습니다. 2010 이전에 작성된 코드에서 해당 형식에 대해 개인 정의를 제공했을 수 있으며, 이러한 정의가 <stdint.h> 정의와 일치하지 않을 수도 있습니다.

오류가 C2371이고 stdint 형식이 관련된 경우 해당 형식이 코드 또는 타사 lib 파일의 헤더에서 정의된 것입니다. 업그레이드 시 <stdint.h> 형식의 사용자 지정 정의를 모두 제거해야 하지만 먼저 사용자 지정 정의를 현재 표준 정의와 비교하여 새로운 문제가 도입되지 않도록 해야 합니다.

F12 키, 정의로 이동을 눌러 해당 형식이 정의된 위치를 확인할 수 있습니다.

여기서는 /showIncludes 컴파일러 옵션이 유용할 수 있습니다. 프로젝트에 대한 속성 페이지 대화 상자에서 C/C++, 고급 페이지를 열고 포함 표시로 설정합니다. 그런 다음 프로젝트를 다시 빌드하고 출력 창에서 #includes 목록을 확인합니다. 각 헤더는 포함하는 헤더 아래에 들여쓰기됩니다.

CRT 함수와 관련된 오류

지난 몇 년 동안 C 런타임에서 많은 변화가 있었습니다. 함수의 보안 버전이 많이 추가되었으며 일부는 제거되었습니다. 또한 이 문서의 앞부분에서 설명한 대로, Microsoft의 CRT 구현이 Visual Studio 2015에서 새로운 이진 파일 및 관련 .lib 파일에 리팩터링되었습니다.

오류가 CRT 함수와 관련된 경우 Visual C++ 변경 기록 2003 - 2015 또는 Visual Studio 2017의 C++ 규칙 향상을 검색하여 해당 항목에 추가 정보가 들어 있는지 확인합니다. 오류가 LNK2019, 확인할 수 없는 외부 참조인 경우 함수가 제거되지 않았는지 확인합니다. 또는 함수가 확실히 존재하고 호출 코드가 올바른 경우 프로젝트에서 /NODEFAULTLIB를 사용하는지 확인합니다. 사용하는 경우 프로젝트에서 새로운 유니버설(UCRT) 라이브러리를 사용하도록 라이브러리 목록을 업데이트해야 합니다. 자세한 내용은 라이브러리 및 종속성에 대한 위 섹션을 참조하세요.

오류가 printf 또는 scanf와 관련된 경우 stdio.h를 포함하지 않고 개인적으로 함수를 정의하지 않았는지 확인합니다. 개인적으로 정의한 경우 개인 정의를 제거하거나 legacy_stdio_definitions.lib에 연결합니다(프로젝트 | 속성 | 링커 | 링커 입력). Windows SDK 8.1 이전 버전에 연결하는 경우 legacy_stdio_definitions.lib를 추가합니다.

오류가 형식 문자열 인수와 관련된 경우 컴파일러가 표준 적용에 대해 보다 엄격하기 때문입니다. 자세한 내용은 변경 기록을 참조하세요. 여기에 포함된 오류는 잠재적으로 보안 위험을 나타낼 수 있으므로 특히 주의하세요.

C++ 표준의 변경 내용으로 인한 오류

C++ 표준 자체가 이전 버전과 항상 호환되지는 않는 방식으로 발전해 왔습니다. 이동 의미 체계, 새로운 키워드, 기타 언어 및 표준 라이브러리 기능으로 이루어진 C++11이 도입되면서 잠재적으로 컴파일러 오류와 다른 런타임 동작이 발생할 수 있습니다.

예를 들어 이전 C++ 프로그램에 iostream.h 헤더가 있을 수 있습니다. 이 헤더는 C++의 초기에 사용이 중단되었으며 결국 Visual C++에서 완전히 제거되었습니다. 이 경우 <iostream>을 사용하고 코드를 다시 작성해야 합니다. 자세한 내용은 이전 iostreams 코드 업데이트를 참조하세요.

C4838: 축소 변환 경고

이제 C++ 표준에서 부호 없는 정수 계열 값에서 부호 있는 정수 계열 값으로의 변환을 축소 변환으로 간주하도록 지정합니다. Visual Studio 2015 이전에는 Visual C++ 컴파일러에서 이 경고가 발생하지 않았습니다. 각 항목을 검사하여 축소가 코드의 정확성에 영향을 주지 않는지 확인해야 합니다.

보안 CRT 함수를 사용하도록 경고

지난 몇 년 동안 C 런타임 함수의 보안 버전이 도입되었습니다. 오래된 비보안 버전도 계속 사용할 수 있지만 보안 버전을 사용하도록 코드를 변경하는 것이 좋습니다. 컴파일러에서 비보안 버전의 사용에 대한 경고가 발생합니다. 이러한 경고를 사용하지 않거나 무시하도록 선택할 수 있습니다. 솔루션의 모든 프로젝트에 대해 경고를 사용하지 않으려면 보기 | 속성 관리자를 열고 경고를 사용하지 않을 프로젝트를 모두 선택한 다음 선택한 항목을 마우스 오른쪽 단추로 클릭하고 속성 | C/C++ | 고급 | 특정 경고 사용 안 함을 선택합니다. 드롭다운 화살표를 클릭한 다음 편집을 클릭합니다. 텍스트 상자에 4996을 입력합니다. 'C' 접두사를 포함하지 마세요. 자세한 내용은 보안 CRT를 사용하도록 포팅을 참조하세요.

Windows API의 변경 내용 또는 오래된 SDK로 인한 오류

지난 몇 년 동안 Windows API와 데이터 형식이 추가되었으며, 때로는 변경되거나 제거되었습니다. 또한 핵심 운영 체제에 속하지 않는 다른 SDK가 등장하고 사라졌습니다. 따라서 오래된 프로그램에는 더 이상 존재하지 않는 API 호출이 있을 수 있습니다. 또한 더 이상 지원되지 않는 다른 Microsoft SDK의 API 호출이 있는 경우도 있습니다. Windows API 또는 이전 Microsoft SDK의 API와 관련된 오류가 표시되는 경우 API가 제거되었거나 최신 보안 함수로 대체되었을 수 있습니다.

현재 API 집합과 특정 Windows API에 지원되는 최소 운영 체제에 대한 자세한 내용을 보려면 Windows API 인덱스를 참조하고 해당 API로 이동합니다.

Windows 버전

Windows API를 직접 또는 간접적으로 사용하는 프로그램을 업그레이드하는 경우 지원할 최소 Windows 버전을 결정해야 합니다. 대부분의 경우 Windows 7을 선택하는 것이 좋습니다. 자세한 내용은 헤더 파일 문제를 참조하세요. WINVER 매크로는 프로그램이 실행되도록 설계된 가장 오래된 Windows 버전을 정의합니다. MFC 프로그램이 WINVER을 0x0501(Windows XP)로 설정하는 경우 MFC에서 XP를 더 이상 지원하기 않으므로 컴파일러 자체에 XP 모드가 있어도 경고가 발생합니다.

자세한 내용은 대상 Windows 버전 업데이트더 오래된 헤더 파일을 참조하세요.

ATL/MFC

ATL 및 MFC는 비교적 안정된 API이지만 때때로 변경됩니다. 자세한 내용은 Visual C++ 변경 기록 2003 – 2015, Visual Studio 2017의 Visual C++에 대한 새로운 기능Visual Studio 2017의 C++ 규칙 향상을 참조하세요.

LNK 2005 _DllMain@12가 MSVCRTD.lib에 이미 정의되어 있습니다.

이 오류는 MFC 응용 프로그램에서 발생할 수 있습니다. CRT 라이브러리와 MFC 라이브러리 간의 순서 지정 문제를 나타냅니다. MFC에서 new 및 delete 연산자를 제공하도록 연결해야 합니다. 오류를 해결하려면 /NODEFAULTLIB 스위치를 사용하여 기본 라이브러리 MSVCRTD.lib 및 mfcs140d.lib를 무시합니다. 그런 다음 동일한 라이브러리를 추가 종속성으로 추가합니다.

32비트 및 64비트

원래 코드가 32비트 시스템용으로 컴파일된 경우 새로운 32비트 앱 대신(또는 추가로) 64비트 버전을 만들 수 있습니다. 일반적으로 먼저 32비트 모드로 프로그램을 컴파일한 다음 64비트를 시도해야 합니다. 64비트용 컴파일 작업은 간단하지만, 경우에 따라 32비트 빌드에서 숨겨진 버그가 나타날 수 있습니다.

또한 printf 및 scanf 함수의 포인터 크기, 시간 및 크기 값, 형식 지정자와 관련된 가능한 컴파일 시간 및 런타임 문제에 주의해야 합니다. 자세한 내용은 64비트용 프로그램 구성(Visual C++)일반적인 Visual C++ 64비트 마이그레이션 문제를 참조하세요. 추가 마이그레이션 팁은 64비트 Windows에 대한 프로그래밍 가이드를 참조하세요.

유니코드 및 MBCS/ASCII

유니코드가 표준화되기 전에는 대부분의 프로그램이 MBCS(멀티바이트 문자 집합)를 사용하여 ASCII 문자 집합에 포함되지 않은 문자를 표현했습니다. 이전 MFC 프로젝트에서는 MBCS가 기본 설정이었으며, 이러한 프로그램을 업그레이드하는 경우 대신 유니코드를 사용하라는 경고가 표시됩니다. 유니코드로 변환이 개발 비용의 가치가 없다고 결정하는 경우 경고를 사용하지 않거나 무시하도록 선택할 수 있습니다. 솔루션의 모든 프로젝트에 대해 경고를 사용하지 않으려면 보기 | 속성 관리자를 열고 경고를 사용하지 않을 프로젝트를 모두 선택한 다음 선택한 항목을 마우스 오른쪽 단추로 클릭하고 속성 | C/C++ | 고급 | 특정 경고 사용 안 함을 선택합니다. 드롭다운 화살표를 클릭한 다음 편집을 클릭합니다. 텍스트 상자에 4996을 입력합니다. 'C' 접두사를 포함하지 마세요.

자세한 내용은 MBCS에서 유니코드로 포팅을 참조하세요. MBCS 및 유니코드에 대한 일반적인 내용은 Visual C++의 텍스트 및 문자열국제화를 참조하세요.

참고 항목

이전 버전의 Visual C++에서 프로젝트 업그레이드 Visual Studio 2017의 C++ 규칙 향상