Gambaran umum potensi masalah peningkatan (Visual C++)

Selama bertahun-tahun, pengkompilasi Microsoft C++ telah mengalami banyak perubahan, bersama dengan perubahan dalam bahasa C++ itu sendiri, Pustaka Standar C++, runtime C (CRT), dan pustaka lain seperti MFC dan ATL. Akibatnya, ketika Anda meningkatkan aplikasi dari versi Visual Studio yang lebih lama, Anda mungkin melihat kesalahan dan peringatan pengkompilasi dan linker dalam kode yang sebelumnya dikompilasi dengan bersih. Semakin lama basis kode asli, semakin besar potensi kesalahan tersebut. Gambaran umum ini merangkum kelas masalah yang paling umum yang mungkin Anda lihat, dan menyediakan tautan ke informasi yang lebih rinci.

Catatan

Di masa lalu, kami merekomendasikan agar peningkatan yang mencakup beberapa versi Visual Studio harus dilakukan secara bertahap satu versi pada satu waktu. Kami tidak lagi merekomendasikan pendekatan ini. Kami telah menemukan bahwa hampir selalu lebih sederhana untuk meningkatkan ke versi Visual Studio terbaru tidak peduli berapa lama basis kode.

Pertanyaan atau komentar tentang proses peningkatan dapat dikirim ke vcupgrade@microsoft.com.

Dependensi pustaka dan toolset

Catatan

Bagian ini berlaku untuk aplikasi dan pustaka yang dibangun dengan Visual Studio 2013 dan yang lebih lama. Toolset yang digunakan di Visual Studio 2015, Visual Studio 2017, dan Visual Studio 2019 kompatibel dengan biner. Untuk informasi selengkapnya, lihat Kompatibilitas Biner C++ antar versi Visual Studio.

Saat Anda meningkatkan aplikasi dari Visual Studio 2013 atau sebelum ke versi yang lebih baru, seringkali disarankan dan perlu untuk meningkatkan semua pustaka dan DLL yang ditautkan aplikasi. Anda harus memiliki akses ke kode sumber, atau vendor pustaka harus menyediakan file biner baru yang dikompilasi dengan versi utama pengkompilasi yang sama. Jika salah satu kondisi ini benar, maka Anda dapat melewati bagian ini, yang berkaitan dengan detail kompatibilitas biner. Jika tidak demikian, pustaka mungkin tidak berfungsi di aplikasi Anda yang ditingkatkan. Informasi di bagian ini akan membantu Anda memahami apakah Anda dapat melanjutkan peningkatan.

Toolset

.obj Format file dan .lib didefinisikan dengan baik dan jarang berubah. Terkadang penambahan dilakukan untuk format file ini, tetapi penambahan ini umumnya tidak memengaruhi kemampuan toolset yang lebih baru untuk mengonsumsi file objek dan pustaka yang diproduksi oleh toolset yang lebih lama. Pengecualian utama adalah jika Anda mengkompilasi menggunakan /GL (pengoptimalan Program Siapa le). Jika Anda mengkompilasi menggunakan /GL, Anda hanya dapat menautkan file objek yang dihasilkan dengan menggunakan set alat yang sama yang digunakan untuk menghasilkannya. Jadi, jika Anda menghasilkan file objek dengan /GL dan menggunakan pengkompilasi Visual Studio 2017 (v141), Anda harus menautkannya menggunakan linker Visual Studio 2017 (v141). Ini karena struktur data internal dalam file objek tidak stabil di seluruh versi utama toolset. Toolset yang lebih baru tidak memahami format data yang lebih lama.

C++ tidak memiliki antarmuka biner aplikasi (ABI) yang stabil. Tetapi Visual Studio mempertahankan C++ ABI yang stabil untuk semua versi minor rilis. Alat Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142), dan Visual Studio 2022 (v143) hanya bervariasi dalam versi minornya. Mereka semua memiliki nomor versi utama yang sama, yaitu 14. Untuk informasi selengkapnya, lihat Kompatibilitas Biner C++ antar versi Visual Studio.

Jika Anda memiliki file objek yang memiliki simbol eksternal dengan tautan C++, file objek tersebut mungkin tidak ditautkan dengan benar dengan file objek yang dihasilkan oleh versi utama set alat yang berbeda. Ada banyak kemungkinan hasil: tautan mungkin gagal sepenuhnya (misalnya, jika dekorasi nama berubah). Tautan dapat berhasil, tetapi aplikasi dapat gagal pada runtime (misalnya, jika tata letak jenis berubah). Atau aplikasi Anda mungkin terus berfungsi dan tidak ada yang salah. Perhatikan juga, meskipun ABI C++ tidak stabil, C ABI dan subset ABI C++ yang diperlukan untuk COM stabil.

Jika Anda menautkan ke pustaka impor, versi pustaka Visual Studio yang dapat didistribusikan ulang visual studio yang mempertahankan kompatibilitas ABI dapat digunakan saat runtime. Misalnya, jika Anda mengkompilasi dan menautkan aplikasi dengan menggunakan toolset Visual Studio 2015 Update 3, Anda dapat menggunakan yang dapat didistribusikan ulang nanti. Itu karena pustaka 2015, 2017, 2019, dan 2022 telah mempertahankan kompatibilitas biner mundur. Kebalikannya tidak benar: Anda tidak dapat menggunakan yang dapat didistribusikan ulang untuk versi toolset yang lebih lama daripada yang Anda gunakan untuk membangun komponen kode Apa pun.

Pustaka

Jika Anda #include versi tertentu dari file header, Anda harus menautkan file objek yang dihasilkan ke versi pustaka yang sama. Jadi, misalnya, jika file sumber Anda menyertakan Visual Studio 2015 Update 3 <immintrin.h>, Anda harus menautkan dengan pustaka Visual Studio 2015 Update 3 vcruntime . Demikian pula, jika file sumber Anda menyertakan Visual Studio 2017 versi 15.5 <iostream>, Anda harus menautkan dengan pustaka Visual Studio 2017 versi 15.5 Standard C++, msvcprt. Pencampuran dan pencocokan tidak didukung.

Untuk Pustaka Standar C++, pencampuran dan pencocokan secara eksplisit tidak diizinkan oleh penggunaan #pragma detect_mismatch di header standar sejak Visual Studio 2010. Jika Anda mencoba menautkan file objek yang tidak kompatibel, atau jika Anda menautkan dengan pustaka standar yang salah, tautan gagal.

Pencampuran dan pencocokan versi CRT yang lebih lama tidak pernah didukung, tetapi sering kali hanya berfungsi karena permukaan API tidak banyak berubah dari waktu ke waktu. Universal CRT memecah kompatibilitas mundur sehingga di masa depan kita dapat mempertahankan kompatibilitas mundur. Kami tidak memiliki rencana untuk memperkenalkan biner Universal CRT versi baru di masa mendatang. Sebagai gantinya, Universal CRT yang ada sekarang diperbarui di tempat.

Untuk menyediakan kompatibilitas tautan parsial dengan file objek (dan pustaka) yang dikompilasi dengan versi header Microsoft C Runtime yang lebih lama, kami menyediakan pustaka, legacy_stdio_definitions.lib, dengan Visual Studio 2015 dan yang lebih baru. Pustaka ini menyediakan simbol kompatibilitas untuk sebagian besar fungsi dan ekspor data yang dihapus dari Universal CRT. Kumpulan simbol kompatibilitas yang disediakan oleh legacy_stdio_definitions.lib cukup untuk memenuhi sebagian besar dependensi, termasuk semua dependensi dalam pustaka yang disertakan dalam Windows SDK. Namun, beberapa simbol dihapus dari Universal CRT yang tidak memiliki simbol kompatibilitas. Simbol-simbol ini mencakup beberapa fungsi (misalnya, __iob_func) dan beberapa ekspor data (misalnya, __imp___iob, , __imp___pctype__imp___mb_cur_max).

Jika Anda memiliki pustaka statis yang dibangun dengan menggunakan versi header C Runtime yang lebih lama, kami merekomendasikan tindakan berikut, dalam urutan ini:

1. Bangun ulang pustaka statis menggunakan versi baru Visual Studio dan header Universal CRT untuk mendukung penautan dengan Universal CRT. Pendekatan ini didukung penuh, dan opsi terbaik.

2. Jika Anda tidak dapat (atau tidak ingin) membangun kembali pustaka statis, Anda dapat mencoba menautkan dengan legacy_stdio_definitions.lib. Jika memenuhi dependensi waktu tautan pustaka statis Anda, Anda harus menguji pustaka statis secara menyeluruh seperti yang digunakan dalam biner. Pastikan itu tidak terpengaruh secara merugikan oleh salah satu perubahan perilaku yang dilakukan pada Universal CRT.

3. Mungkin dependensi pustaka statis Anda tidak terpenuhi oleh legacy_stdio_definitions.lib atau pustaka tidak berfungsi dengan Universal CRT karena perubahan perilaku. Dalam hal ini, kami sarankan Anda merangkum pustaka statis Anda ke dalam DLL yang Anda tautkan dengan versi Microsoft C Runtime yang diperlukan. Misalnya, jika pustaka statis dibuat menggunakan Visual Studio 2013, buat DLL ini menggunakan toolset Visual Studio 2013 dan pustaka C++ juga. Dengan membangun pustaka ke dll, Anda merangkum detail implementasi yang merupakan dependensinya pada versi Tertentu dari Microsoft C Runtime. Berhati-hatilah antarmuka DLL tidak membocorkan detail C Runtime mana yang digunakannya, misalnya, jika mengembalikan FILE* di seluruh batas DLL, atau mallocpenunjuk -yang dialokasikan, pemanggil harus free.

Penggunaan beberapa CRT dalam satu proses tidak dalam dan dari dirinya sendiri bermasalah. (Bahkan, sebagian besar proses memuat beberapa DLL CRT. Misalnya, komponen sistem operasi Windows bergantung pada msvcrt.dll, dan CLR tergantung pada CRT privatnya sendiri.) Masalah muncul ketika Anda beradu status dari CRTs yang berbeda. Misalnya, Anda tidak boleh mengalokasikan memori menggunakan msvcr110.dll!malloc dan mencoba membatalkan alokasi memori tersebut menggunakan msvcr120.dll!free, dan Anda tidak boleh mencoba membuka FILE menggunakan msvcr110!fopen dan mencoba membaca dari FILE tersebut menggunakan msvcr120!fread. Selama Anda tidak beradu status dari CRTs yang berbeda, Anda dapat dengan aman memiliki beberapa CRT yang dimuat dalam satu proses.

Untuk informasi selengkapnya, lihat Meningkatkan kode Anda ke Universal CRT.

Kesalahan yang disebabkan oleh pengaturan proyek

Untuk memulai proses peningkatan, buka proyek/solusi/ruang kerja yang lebih lama di versi terbaru Visual Studio. Visual Studio akan membuat proyek baru berdasarkan pengaturan proyek lama. Periksa apakah proyek lama memiliki jalur pustaka atau sertakan jalur yang dikodekan secara permanen ke lokasi non-standar. Ada kemungkinan file di jalur tersebut tidak akan terlihat oleh pengkompilasi saat proyek menggunakan pengaturan default. Untuk informasi selengkapnya, lihat Pengaturan Linker OutputFile.

Secara umum, sekarang adalah waktu yang tepat untuk mengatur kode proyek Anda untuk menyederhanakan pemeliharaan proyek dan membantu mendapatkan kode yang ditingkatkan untuk dibangun secepat mungkin. Jika kode sumber Anda sudah terorganisir dengan baik, dan proyek lama Anda dikompilasi di bawah Visual Studio 2010 atau yang lebih baru, Anda dapat mengedit file proyek baru secara manual untuk mendukung kompilasi pada kompilator lama dan baru. Contoh berikut menunjukkan cara mengkompilasi untuk Visual Studio 2015 dan Visual Studio 2017:

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

LNK2019: Eksternal tidak terselesaikan

Untuk simbol yang belum terselesaikan, Anda mungkin perlu memperbaiki pengaturan proyek Anda.

• Jika file sumber berada di lokasi non-default, apakah Anda menambahkan jalur ke direktori sertakan proyek?

• Jika eksternal ditentukan dalam .lib file, sudahkah Anda menentukan jalur lib di properti proyek, dan apakah versi file yang benar terletak di .lib sana?

• Apakah Anda mencoba menautkan ke .lib file yang dikompilasi dengan versi Visual Studio yang berbeda? Jika demikian, lihat bagian sebelumnya tentang dependensi pustaka dan toolset.

• Apakah jenis argumen di situs panggilan benar-benar cocok dengan kelebihan fungsi yang ada? Verifikasi jenis yang mendasar adalah apa yang Anda harapkan, baik untuk typedef apa pun dalam tanda tangan fungsi dan dalam kode yang memanggil fungsi.

Untuk memecahkan masalah kesalahan simbol yang tidak terselesaikan, Anda dapat menggunakan dumpbin.exe untuk memeriksa simbol yang ditentukan dalam biner. Coba baris perintah berikut untuk melihat simbol yang ditentukan dalam pustaka:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Adalah Jenis Asli)

(Di Microsoft Visual C++ 6.0 dan yang lebih lama, wchar_t tidak diimplementasikan sebagai jenis bawaan. Ini dinyatakan sebagai wchar.h typedef untuk unsigned short.) Standar C++ mengharuskan jenis wchar_t bawaan. Menggunakan versi typedef dapat menyebabkan masalah portabilitas. Jika Anda meningkatkan dari versi Visual Studio sebelumnya dan melihat kesalahan pengkompilasi C2664 karena kode mencoba mengonversi secara implisit ke wchar_tunsigned short, kami sarankan Anda mengubah kode untuk memperbaiki kesalahan, alih-alih mengatur /Zc:wchar_t-. Untuk informasi selengkapnya, lihat /Zc:wchar_t (wchar_t Jenis Asli).

Memutakhirkan dengan opsi /NODEFAULTLIBlinker , , /ENTRYdan /NOENTRY

Opsi /NODEFAULTLIB linker (atau properti abaikan semua pustaka default linker) memberi tahu linker untuk tidak secara otomatis menautkan di pustaka default seperti CRT. Ini berarti bahwa setiap pustaka harus terdaftar sebagai input satu per satu. Daftar pustaka ini diberikan di properti Dependensi Tambahan di bagian Linker dari dialog Properti Proyek.

Proyek yang menggunakan opsi ini menyajikan masalah saat memutakhirkan, karena konten beberapa pustaka default direfaktor. Karena setiap pustaka harus tercantum di properti Dependensi Tambahan atau pada baris perintah linker, Anda perlu memperbarui daftar pustaka untuk menggunakan semua nama saat ini.

Tabel berikut ini memperlihatkan pustaka yang kontennya berubah dimulai dengan Visual Studio 2015. Untuk meningkatkan, Anda perlu menambahkan nama pustaka baru di kolom kedua ke pustaka di kolom pertama. Beberapa pustaka ini adalah pustaka impor, tetapi itu seharusnya tidak masalah.

Jika Anda menggunakan:	Anda perlu menggunakan pustaka ini:
libcmt.lib	libcmt.lib, libucrt.lib, libvcruntime.lib
libcmtd.lib	libcmtd.lib, libucrtd.lib, libvcruntimed.lib
msvcrt.lib	msvcrt.lib, ucrt.lib, vcruntime.lib
msvcrtd.lib	msvcrtd.lib, ucrtd.lib, vcruntimed.lib

Masalah yang sama berlaku juga jika Anda menggunakan /ENTRY opsi atau /NOENTRY opsi , yang juga memiliki efek melewati pustaka default.

Kesalahan yang disebabkan oleh peningkatan kesuaian bahasa

Pengkompilasi Microsoft C++ terus meningkatkan kesuaiannya dengan standar C++ selama bertahun-tahun. Kode yang dikompilasi dalam versi sebelumnya mungkin gagal dikompilasi di versi Visual Studio yang lebih baru. Itu karena pengkompilasi menandai kesalahan yang sebelumnya diabaikan atau diizinkan secara eksplisit.

Misalnya, sakelar /Zc:forScope diperkenalkan lebih awal dalam riwayat MSVC. Ini mengizinkan perilaku yang tidak sesuai untuk variabel perulangan. Sakelar tersebut sekarang tidak digunakan lagi dan mungkin dihapus dalam versi mendatang. Kami sangat menyarankan Anda untuk tidak menggunakan sakelar tersebut saat meningkatkan kode Anda. Untuk informasi selengkapnya, lihat /Zc:forScope- tidak digunakan lagi.

Salah satu contoh kesalahan kompilator umum yang mungkin Anda lihat saat meningkatkan adalah ketika argumen non-const diteruskan ke parameter const. Versi kompilator yang lebih lama tidak selalu menandainya sebagai kesalahan. Untuk informasi selengkapnya, lihat Konversi kompilator yang lebih ketat.

Untuk informasi selengkapnya tentang peningkatan kesuaian tertentu, lihat Riwayat perubahan Visual C++ 2003 - 2015 dan peningkatan kesuaian C++ di Visual Studio.

Kesalahan yang <stdint.h> melibatkan jenis integral

Header <stdint.h> mendefinisikan typedefs dan makro yang, tidak seperti jenis integral bawaan, dijamin memiliki panjang yang ditentukan pada semua platform. Beberapa contohnya adalah uint32_t dan int64_t. Header <stdint.h> ditambahkan di Visual Studio 2010. Kode yang ditulis sebelum 2010 mungkin telah memberikan definisi privat untuk jenis tersebut. Dan, definisi tersebut mungkin tidak selalu konsisten dengan <stdint.h> definisi.

Jika kesalahannya adalah C2371, dan stdint jenis terlibat, itu mungkin berarti bahwa jenis ditentukan dalam header baik dalam kode Anda atau file pustaka pihak ketiga. Saat meningkatkan, Anda harus menghilangkan definisi kustom jenis <stdint.h> apa pun, tetapi terlebih dahulu membandingkan definisi kustom dengan definisi standar saat ini untuk memastikan Anda tidak memperkenalkan masalah baru.

Anda dapat menekan F12 (Buka Definisi) untuk melihat di mana jenis yang dimaksud ditentukan.

Opsi /showIncludes pengkompilasi dapat berguna di sini. Dalam kotak dialog Halaman Properti untuk proyek Anda, pilih halaman Properti>Konfigurasi C/C++>Tingkat Lanjut dan atur Perlihatkan Sertakan ke Ya. Kemudian bangun kembali proyek Anda. Anda akan melihat daftar #include file di jendela output. Setiap header diindentasi di bawah header yang menyertakannya.

Kesalahan yang melibatkan fungsi CRT

Banyak perubahan telah dilakukan pada runtime C selama bertahun-tahun. Banyak versi fungsi aman telah ditambahkan, dan beberapa telah dihapus. Selain itu, seperti yang dijelaskan sebelumnya dalam artikel ini, implementasi CRT Microsoft direfaktor di Visual Studio 2015 ke biner baru dan file terkait .lib .

Jika kesalahan melibatkan fungsi CRT, cari Riwayat perubahan Visual C++ 2003 - 2015 atau C++ peningkatan kesuaian di Visual Studio untuk melihat apakah artikel tersebut berisi informasi tambahan. Jika kesalahan LNK2019, pastikan fungsi belum dihapus. Jika tidak, jika Anda yakin fungsi masih ada, dan kode panggilan sudah benar, periksa untuk melihat apakah proyek Anda menggunakan /NODEFAULTLIB. Jika demikian, Anda perlu memperbarui daftar pustaka untuk menggunakan pustaka universal (UCRT) baru. Untuk informasi selengkapnya, lihat bagian di atas tentang Pustaka dan dependensi.

Jika kesalahan melibatkan printf atau scanf, pastikan Anda tidak menentukan salah satu fungsi secara privat tanpa menyertakan stdio.h. Jika demikian, hapus definisi privat atau tautkan ke legacy_stdio_definitions.lib. Anda dapat mengatur pustaka ini dalam dialog Halaman Properti di bawah Input Linker>Properti>Konfigurasi, di properti Dependensi Tambahan. Jika Anda menautkan dengan Windows SDK 8.1 atau yang lebih lama, tambahkan legacy_stdio_definitions.lib.

Jika kesalahan melibatkan argumen string format, itu mungkin karena pengkompilasi lebih ketat tentang memberlakukan standar. Untuk informasi selengkapnya, lihat riwayat perubahan. Perhatikan dengan ketat kesalahan apa pun di sini, karena berpotensi mewakili risiko keamanan.

Kesalahan yang disebabkan oleh perubahan standar C++

Standar C++ sendiri telah berkembang dengan cara yang tidak selalu kompatibel mundur. C++11 memperkenalkan semantik pemindahan, kata kunci baru, serta fitur bahasa dan pustaka standar lainnya. Perubahan ini berpotensi menyebabkan kesalahan kompilator dan bahkan perilaku runtime yang berbeda.

Misalnya, program C++ lama mungkin menyertakan iostream.h header . Header ini tidak digunakan lagi awal dalam riwayat C++ dan akhirnya dihapus sepenuhnya dari Visual Studio. Dalam hal ini, Anda perlu menggunakan <iostream> dan menulis ulang kode Anda. Untuk informasi selengkapnya, lihat Memperbarui kode lamaiostream.

C4838: mempersempit peringatan konversi

Standar C++ sekarang menentukan bahwa konversi dari yang tidak ditandatangani ke nilai integral yang ditandatangani mempersempit konversi. Pengkompilasi tidak menaikkan peringatan ini sebelum Visual Studio 2015. Periksa setiap kemunculan untuk memastikan penyempitan tidak memengaruhi kebenaran kode Anda.

Peringatan untuk menggunakan fungsi CRT aman

Selama bertahun-tahun, versi aman fungsi runtime C telah diperkenalkan. Meskipun versi lama yang tidak aman masih tersedia, disarankan untuk mengubah kode Anda untuk menggunakan versi aman. Pengkompilasi akan mengeluarkan peringatan untuk penggunaan versi yang tidak aman. Anda dapat memilih untuk menonaktifkan atau mengabaikan peringatan ini. Untuk menonaktifkan peringatan untuk semua proyek dalam solusi Anda, buka Tampilkan>Pengelola Properti, pilih semua proyek yang ingin Anda nonaktifkan peringatannya, lalu klik kanan pada item yang dipilih dan pilih Properti. Dalam dialog Halaman Properti di bawah Properti>Konfigurasi C/C++>Tingkat Lanjut, pilih Nonaktifkan Peringatan Tertentu. Pilih panah turun bawah lalu pilih Edit. Masukkan 4996 ke dalam kotak teks. (Jangan sertakan awalan 'C'.) Untuk informasi selengkapnya, lihat Porting untuk menggunakan Secure CRT.

Kesalahan yang disebabkan oleh perubahan api Windows atau SDK usang

Selama bertahun-tahun, API Windows dan jenis data telah ditambahkan, dan terkadang diubah atau dihapus. Selain itu, SDK lain yang bukan milik sistem operasi inti telah datang dan pergi. Program lama mungkin berisi panggilan ke API yang tidak lagi ada. Mereka mungkin juga berisi panggilan ke API di Microsoft SDK lain yang tidak lagi didukung. Anda dapat melihat kesalahan tentang API atau API Windows yang hilang dari Microsoft SDK yang lebih lama. Ada kemungkinan API dihapus atau digantikan oleh fungsi yang lebih baru dan lebih aman.

Dokumentasi WINDOWS API mencantumkan sistem operasi minimum atau maksimum yang didukung. Untuk informasi tentang WINDOWS API tertentu, cari di Indeks API untuk aplikasi Windows desktop.

Versi Windows

Saat memutakhirkan program yang menggunakan Windows API baik secara langsung maupun tidak langsung, Anda perlu memutuskan versi Windows minimum yang akan didukung. Dalam kebanyakan kasus, Windows 7 adalah pilihan yang baik. Untuk informasi selengkapnya, lihat Masalah file header. WINVER Makro mendefinisikan versi Windows terlama yang dirancang untuk dijalankan oleh program Anda. Jika program MFC Anda diatur WINVER ke 0x0501 (Windows XP), Anda akan mendapatkan peringatan karena MFC tidak lagi mendukung XP, bahkan jika toolset kompilator itu sendiri memiliki mode XP. Dukungan toolset compiler untuk Windows XP berakhir di Visual Studio 2017.

Untuk informasi selengkapnya, lihat Memperbarui versi windows target dan File header yang lebih lama.

ATL / MFC

ATL dan MFC adalah API yang relatif stabil tetapi perubahan sesekali dilakukan. Untuk informasi selengkapnya, lihat Riwayat perubahan Visual C++ 2003 - 2015, Apa yang baru untuk Visual C++ di Visual Studio, dan peningkatan kesuaian C++ di Visual Studio.

LNK 2005 _DllMain@12 sudah ditentukan dalam MSVCRTD.lib

Kesalahan ini dapat terjadi di aplikasi MFC. Ini menunjukkan masalah pemesanan antara pustaka CRT dan pustaka MFC. MFC harus ditautkan terlebih dahulu sehingga menyediakan new dan delete operator. Untuk memperbaiki kesalahan, gunakan tombol /NODEFAULTLIB untuk Mengabaikan pustaka default ini: MSVCRTD.lib dan mfcs140d.lib. Kemudian tambahkan pustaka yang sama ini sebagai dependensi tambahan.

32 vs 64 bit

Jika kode asli Anda dikompilasi untuk sistem 32-bit, Anda memiliki opsi untuk membuat versi 64-bit alih-alih (atau selain) aplikasi 32-bit baru. Secara umum, Anda harus mengkompilasi program Anda dalam mode 32-bit terlebih dahulu, lalu mencoba 64-bit. Mengompilasi untuk 64-bit sangat mudah, tetapi dalam beberapa kasus dapat mengungkapkan bug yang disembunyikan oleh build 32-bit.

Selain itu, Anda harus mengetahui kemungkinan masalah waktu kompilasi dan runtime yang berkaitan dengan ukuran penunjuk, nilai waktu dan ukuran, dan penentu format khusus ukuran dalam printf dan scanf fungsi. Untuk informasi selengkapnya, lihat Mengonfigurasi Visual C++ untuk target 64-bit, x64, dan masalah migrasi Common Visual C++ 64-bit. Untuk tips migrasi lainnya, lihat Panduan pemrograman untuk Windows 64-bit.

Unicode vs MBCS/ASCII

Sebelum Unicode distandarkan, banyak program menggunakan Multibyte Character Set (MBCS) untuk mewakili karakter yang tidak disertakan dalam set karakter ASCII. Dalam proyek MFC yang lebih lama, MBCS adalah pengaturan default. Ketika Anda meningkatkan program seperti itu, Anda akan melihat peringatan yang menyarankan untuk menggunakan Unicode sebagai gantinya. Jika Anda memutuskan konversi ke Unicode tidak sepadan dengan biaya pengembangan, Anda dapat memilih untuk menonaktifkan atau mengabaikan peringatan. Untuk menonaktifkannya untuk semua proyek dalam solusi Anda, buka Tampilkan>Pengelola Properti, pilih semua proyek yang ingin Anda nonaktifkan peringatannya, lalu klik kanan pada item yang dipilih dan pilih Properti. Dalam dialog Halaman Properti, pilih Properti>Konfigurasi C/C++>Tingkat Lanjut. Di properti Nonaktifkan Peringatan Tertentu, buka panah drop-down, lalu pilih Edit. Masukkan 4996 ke dalam kotak teks. (Jangan sertakan awalan 'C'.) Pilih OK untuk menyimpan properti, lalu pilih OK untuk menyimpan perubahan Anda.

Untuk informasi selengkapnya, lihat Porting dari MBCS ke Unicode. Untuk informasi umum tentang MBCS vs. Unicode, lihat Teks dan String di Visual C++ dan Internasionalisasi .

Baca juga

Meningkatkan proyek dari versi Visual C++ yang lebih lama
Peningkatan kesesuaian C++ di Visual Studio