Các công ty không nâng cấp VS willy-nilly. Chúng tôi đang sử dụng 2010SP1 chẳng hạn trong một dự án không có kế hoạch xuất xưởng trong vài năm. Sử dụng phiên bản mới hơn có nghĩa là mua giấy phép mới cho IDE, khả năng mua giấy phép mới cho các plugin chúng tôi sử dụng và tất nhiên có nguy cơ gặp phải một số lỗi dừng hiển thị chưa được thực hiện. Chúng tôi đã trả tiền cho năm 2010 và biết rằng năm 2010 sẽ đáp ứng nhu cầu của chúng tôi.
Tôi thừa nhận nó đôi khi làm phiền tôi; Tôi thực sự muốn hỗ trợ C ++ 11/14 mới nhất, hỗ trợ AMP và tối ưu hóa được cải thiện, nhưng kiểu "nâng cấp lên độ sáng bóng mới" không phù hợp với các dự án lớn hơn, nghiêm túc hơn.
Hầu hết các thực thể công ty đều rất, rất bảo thủ về việc cập nhật bất kỳ phần mềm nào, có thể là Visual Studio, Office, Windows, Perforce, bất cứ điều gì. Trong khi việc sử dụng Visual Studio 2005 là khá hiếm đối với các trò chơi ngày nay, thì năm 2008 vẫn còn khá phổ biến. Rất rất ít người đang sử dụng 2012. Hoàn toàn có thể là sự hấp thụ của năm 2012 sẽ không bao giờ xảy ra và phiên bản phổ biến tiếp theo của Visual Studio sẽ là 2013 hoặc 2014.
Ví dụ, xem các bản phân phối Linux hướng đến người đam mê phổ biến nhanh như thế nào so với nhịp phát hành của Redhat Enterprise hoặc Ubuntu LTS. Người dùng gia đình và hobbiest có thể dễ dàng biện minh cho việc nâng cấp và những người đam mê thường kêu gọi họ, nhưng các doanh nghiệp thường muốn có ít thay đổi nhất có thể.
Một yếu tố khác hiện nay là khả năng tương thích XBox 360. Thật ngớ ngẩn khi mua và cài đặt hai phiên bản IDE / trình biên dịch nếu bạn cần một phiên bản cụ thể để tương thích với XBox. Phiên bản tiếp theo nào của VS trở nên phổ biến cho các trò chơi sẽ phụ thuộc phần lớn vào trình biên dịch mà XBox One khuyên dùng cho các phiên bản phát hành của devkits của nó (2012 được sử dụng cho các phiên bản beta được sử dụng cho các trò chơi khởi chạy, nhưng năm 2013 có thể được khuyến nghị sử dụng sau ra mắt tiêu đề).
Về mặt thời gian chạy được sử dụng bởi các trình biên dịch, chúng phải khớp chính xác với trình biên dịch đang sử dụng. Một phần của điều này là do cách thức hoạt động của C và C ++. Các giao diện được xác định bởi các tệp tiêu đề, đây thực sự chỉ là một cách ưa thích để thực hiện cut-n-paste. Xem xét triển lãm A:
void foo(char* name, int length);
Và bây giờ hãy xem xét triển lãm B:
void foo(int length, char* name);
Nếu các hàm C này được bao gồm trong hai phiên bản khác nhau của thời gian chạy, thì cả hai đều là biểu tượng _foonhưng mã được biên dịch để sử dụng một chức năng rõ ràng sẽ không hoạt động cho phiên bản kia. Mặc dù các vấn đề tương thích thường liên quan và tinh tế hơn một chút, kết quả cuối cùng vẫn giống nhau: mã được biên dịch với VS2005 sẽ có tiêu đề từ VS2005 chỉ mô tả cách hoạt động của thời gian chạy VS2005. Các tàu VS2012 với các tiêu đề hoàn toàn khác nhau nhắm mục tiêu thời gian chạy hoàn toàn khác nhau.
Microsoft không hỗ trợ nhắm mục tiêu cũ hơn vì đó thực sự sẽ là một nỗi đau. Họ phải vận chuyển và sau đó tiếp tục duy trì các tiêu đề cũ ngoài thời gian chạy. Có rất ít lý do cho nó vì các thực tiễn sử dụng DLL tốt trong Windows cho phép các nhà phát triển trộn các thư viện bằng các thời gian chạy khác nhau. Nếu bạn có VS2012, bạn vẫn có thể liên kết với các thư viện được tạo bằng VS2005, miễn là bạn và thư viện tuân theo một vài quy tắc dễ dàng.
Các nền tảng như GNU / Linux trải qua một số nỗ lực để tránh những vấn đề này, nhưng đã trải qua chúng, đôi khi ở mức độ sâu hơn nhiều. Tôi vẫn nhớ lại quá trình chuyển đổi libc5 sang glibc hoặc thời gian libstdc ++ thường xuyên bị phá vỡ (đây là một lý do khiến các nhà phát triển Linux / UNIX vẫn còn khá lạnh lùng về chủ đề C ++ trong những năm qua).
Windows thực hiện với thời gian chạy C "chung" cấp thấp được gọi MSVCR.DLL, mặc dù mỗi phiên bản của trình biên dịch bao gồm thay thế riêng của nó, ví dụ MSVCRR110.DLL. Bạn có thể nỗ lực chỉ sử dụng phiên bản chung nhưng nó thiếu rất nhiều chức năng, bao gồm hầu hết các thói quen hỗ trợ C ++ thay đổi theo từng phiên bản của Visual Studio (và sự hỗ trợ ngày càng phát triển của C ++). Nói chung, nó không đáng để bỏ công sức và mất chức năng trừ khi bạn thực sự cố gắng tạo một ứng dụng phụ thuộc bằng không (công cụ khôi phục, công cụ hệ điều hành, công cụ bảo mật, v.v. đôi khi rơi vào lớp này).
Nói tóm lại, mỗi Visual Studio có thư viện thời gian chạy riêng và ứng dụng được biên dịch với phiên bản đó phải sử dụng. Các trò chơi thường sẽ được viết bằng cách sử dụng ít hơn trình biên dịch tiên tiến nhất và do đó sẽ yêu cầu thời gian chạy cũ hơn.