Компанії не модернізують VS мимоволі. Наприклад, ми використовуємо 2010SP1 для проекту, який не планується здійснювати протягом декількох років. Використання нової версії означатиме придбання нових ліцензій IDE, можливість придбання нових ліцензій для плагінів, якими ми користуємось, і, звичайно, ризикувати деякими помилками, які не зупиняються на показ. Ми вже заплатили за 2010 рік і знаємо, що 2010 рік буде працювати для наших потреб.
Зізнаюся, це часом мене дратує; Мені б дуже хотілося, щоб найновіша підтримка C ++ 11/14, підтримка AMP та покращені оптимізації, але такий тип "оновлення до нового блискучого" менталітету не добре поєднується з більшими, більш серйозними проектами.
Більшість корпорацій дуже і дуже консервативні щодо оновлення будь-якого програмного забезпечення, будь то Visual Studio, Office, Windows, Perforce і будь-що інше. Хоча використання Visual Studio 2005 є досить рідкісним для ігор сьогодні, 2008 все ще є досить поширеним явищем. Дуже мало хто використовує 2012 рік. Цілком можливо, що 2012 рік ніколи не відбудеться масово і наступною популярною версією Visual Studio буде 2013 або 2014 роки.
Подивіться, наприклад, наскільки швидко загальний, орієнтований на ентузіастів, дистрибутив Linux версії порівняно з частотою випуску Redhat Enterprise або Ubuntu LTS. Домашні користувачі та хобі можуть легше виправдати оновлення, а ентузіасти часто вимагають їх, але підприємства зазвичай хочуть якнайменші зміни.
Ще один фактор сьогодні - сумісність XBox 360. Дурно купувати та встановлювати дві версії IDE / компілятора, якщо вам потрібна, зокрема, для сумісності з XBox. Яка наступна версія VS стане популярною для ігор, багато в чому залежатиме від того, який компілятор XBox One рекомендує випускати версії своїх devkits (2012 використовується для бета-версій devkits, які використовуються для запуску ігор, але 2013 може бути рекомендований вниз по дорозі для запустити заголовки).
Що стосується часу виконання, що використовується компіляторами, вони повинні точно відповідати компілятору, який використовується. Частина цього пов'язана з тим, як працюють C і C ++. Інтерфейси визначаються файлами заголовків, які насправді є просто фантазійним способом зробити cut-n-paste. Розглянемо експонат А:
void foo(char* name, int length);
А тепер розглянемо експонат B:
void foo(int length, char* name);
Якби ці функції C були включені у дві різні версії виконання, вони обидва є символом, _fooале код, зібраний для використання однієї, явно не працював би для іншої. Хоча проблеми сумісності, як правило, дещо задіяні та тонкі, кінцевий результат все одно той самий: код, компільований з VS2005, матиме заголовок від VS2005, який описує лише те, як працює час виконання VS2005. VS2012 поставляється із абсолютно різними заголовками, орієнтованими на зовсім інший час виконання.
Microsoft не підтримує націлювання на старі версії, оскільки це насправді буде просто болем. Їм доведеться відправляти, а потім продовжувати підтримувати старі заголовки, крім часу виконання. Причин для цього досить мало, оскільки хороші практики використання DLL в Windows дозволяють розробникам змішувати бібліотеки, використовуючи різні режими виконання. Якщо у вас є VS2012, ви все ще можете зв’язатись із бібліотеками, створеними з VS2005, якщо ви та бібліотека дотримуєтесь декількох простих правил.
Платформи, такі як GNU / Linux, докладають певних зусиль, щоб уникнути цих проблем, але пройшли через них, іноді на набагато глибшому рівні. Я все ще пригадую перехід libc5 до glibc або часті перерви libstdc ++ (це одна з причин, що розробники Linux / UNIX залишалися відносно холодними на тему C ++ протягом багатьох років).
Windows постачається з низьким рівнем "загального" C часу виконання MSVCR.DLL, хоча кожна версія компілятора включає власну заміну, наприклад MSVCRR110.DLL. Ви можете докласти зусиль, щоб використовувати лише загальну версію, але в ній відсутня велика кількість функціональних можливостей, включаючи більшість процедур підтримки C ++, які змінюються з кожною версією Visual Studio (і її постійно розвивається підтримкою C ++). Зазвичай це не варто зусиль і втрачених функціональних можливостей, якщо ви справді не намагаєтеся зробити додаток з нульовою залежністю (засоби відновлення, засоби ОС, засоби безпеки тощо), іноді не потрапляють до цього класу.
Коротше кажучи, кожна Visual Studio має власну бібліотеку виконання, і програма, складена з цією версією, повинна використовувати. Ігри, як правило, пишуться, використовуючи менше, ніж самий передовий компілятор, а значить, знадобиться старіший час виконання.