Perusahaan tidak mau memperbarui VS mau tak mau. Kami menggunakan 2010SP1 misalnya pada proyek yang tidak berencana untuk dikirim selama beberapa tahun. Menggunakan versi yang lebih baru akan berarti membeli lisensi baru untuk IDE, kemungkinan membeli lisensi baru untuk plugin yang kami gunakan, dan tentu saja mempertaruhkan beberapa bug penghenti acara yang belum berhasil. Kami sudah membayar untuk 2010 dan tahu 2010 akan bekerja untuk kebutuhan kita.
Saya akui itu kadang mengganggu saya; Saya benar-benar ingin dukungan C ++ 11/14 terbaru, dukungan AMP, dan peningkatan optimasi, tetapi mentalitas "upgrade ke yang baru mengkilap" tidak cocok dengan proyek yang lebih besar dan lebih serius.
Sebagian besar entitas perusahaan sangat, sangat konservatif dalam memperbarui perangkat lunak apa pun, baik itu Visual Studio, Office, Windows, Perforce, apa pun. Sementara penggunaan Visual Studio 2005 cukup langka untuk gim saat ini, 2008 masih cukup umum. Sangat sedikit yang menggunakan 2012. Sangat mungkin bahwa serapan tahun 2012 tidak akan pernah terjadi secara massal dan bahwa versi populer berikutnya dari Visual Studio adalah 2013 atau 2014.
Lihat misalnya seberapa cepat distro Linux berorientasi antusias yang umum memperbarui versi dibandingkan dengan irama rilis Redhat Enterprise atau Ubuntu LTS. Pengguna rumahan dan hobbiest dapat lebih mudah membenarkan peningkatan dan penggemar sering menuntut mereka, tetapi bisnis biasanya ingin perubahan sesedikit mungkin.
Faktor lain hari ini adalah kompatibilitas XBox 360. Adalah konyol untuk membeli dan menginstal dua versi IDE / kompiler jika Anda memerlukannya secara khusus untuk kompatibilitas XBox. Versi VS berikutnya yang menjadi populer untuk gim akan sangat tergantung pada kompiler mana yang direkomendasikan oleh XBox One untuk versi rilis para devkitsnya (2012 digunakan untuk para devkits beta yang digunakan untuk meluncurkan gim-gim, tetapi 2013 mungkin akan direkomendasikan untuk post-the road) judul peluncuran).
Dalam hal runtime yang digunakan oleh kompiler, ini harus cocok persis dengan kompiler yang digunakan. Bagian dari ini adalah karena cara kerja C dan C ++. Antarmuka didefinisikan oleh file header, yang sebenarnya hanya cara mewah untuk melakukan cut-n-paste. Pertimbangkan pameran A:
void foo(char* name, int length);
Dan sekarang pertimbangkan pameran B:
void foo(int length, char* name);
Jika fungsi-fungsi C ini dimasukkan dalam dua versi runtimes yang berbeda, keduanya merupakan simbol _footetapi kode yang dikompilasi untuk menggunakan salah satu jelas tidak akan bekerja untuk yang lain. Sementara masalah kompatibilitas umumnya sedikit lebih terlibat dan halus, hasil akhirnya masih sama: kode yang dikompilasi dengan VS2005 akan memiliki header dari VS2005 yang hanya menggambarkan cara kerja runtime VS2005. VS2012 dikirimkan dengan tajuk yang sama sekali berbeda menargetkan runtime yang sama sekali berbeda.
Microsoft tidak mendukung penargetan versi lama karena itu akan sangat merepotkan. Mereka harus mengirim dan kemudian melanjutkan mempertahankan header lama selain runtime. Ada sedikit alasan untuk itu karena praktik penggunaan DLL yang baik di Windows memungkinkan pengembang untuk mencampur perpustakaan menggunakan runtimes yang berbeda. Jika Anda memiliki VS2012 Anda masih dapat menautkan ke perpustakaan yang dibuat dengan VS2005, selama Anda dan perpustakaan mengikuti beberapa aturan mudah.
Platform seperti GNU / Linux mengalami beberapa upaya untuk menghindari masalah ini, tetapi telah melewatinya, kadang-kadang pada tingkat yang jauh lebih dalam. Saya masih ingat transisi libc5 ke glibc, atau seringnya libstdc ++ istirahat (ini adalah salah satu alasan mengapa pengembang Linux / UNIX tetap relatif dingin pada topik C ++ selama bertahun-tahun).
Windows tidak disertakan dengan runtime C "generik" tingkat rendah yang dipanggil MSVCR.DLL, meskipun setiap versi kompiler menyertakan penggantinya sendiri misalnya MSVCRR110.DLL. Anda dapat berupaya menggunakan hanya versi generik tetapi tidak memiliki banyak fungsi, termasuk sebagian besar rutinitas dukungan C ++ yang berubah dengan setiap versi Visual Studio (dan dukungannya yang terus berkembang dari C ++). Biasanya tidak sepadan dengan usaha dan fungsionalitas yang hilang kecuali Anda benar-benar mencoba untuk membuat aplikasi tanpa ketergantungan (alat pemulihan, alat OS, alat keamanan, dan sebagainya kadang-kadang termasuk dalam kelas ini).
Singkatnya, setiap Visual Studio memiliki pustaka runtime sendiri, dan aplikasi yang dikompilasi dengan versi itu harus digunakan. Game biasanya akan ditulis menggunakan kompiler yang paling canggih dan karenanya membutuhkan runtime yang lebih lama.