Các bản cập nhật Visual Studio 2012 có bị hỏng C++ ABI không?

Question

Khi Microsoft phát hành Visual Studio 2012 vào tháng 9 năm 2012, họ đã công bố kế hoạch cung cấp bản cập nhật cho Visual Studio một cách thường xuyên hơn. Kể từ đó, họ đã phát hành Visual Studio 2012 Update 1 (Visual Studio 2012.1) vào tháng 11 năm 2012 và Visual Studio 2012 Update 2 (Visual Studio 2012.2) vào tháng 4 năm 2013.

Câu hỏi của tôi là: Bản cập nhật có giới thiệu bất kỳ thay đổi nào đối với C++ ABI (đối với phiên bản VS2012 ban đầu) không? Có an toàn để liên kết .lib s phiên bản VS2012 khác nhau không?

Tôi đã tìm kiếm Internet trong một thời gian và không thể tìm thấy bất kỳ tuyên bố xác định nào từ Microsoft. Một số sources đề cập đến một số lỗi trong việc tạo mã C++ đã được sửa nhưng tôi cho rằng điều đó không hàm ý một sự thay đổi ABI?

Answer 1

Cuối cùng, tôi tìm thấy câu trả lời cho câu hỏi của tôi trong bài đăng blog Stephan T. Lavavej của C++11/14 STL Features, Fixes, And Breaking Changes In VS 2013:

Cơ chế VS Update là chủ yếu cho xuất xưởng sửa lỗi có mức ưu tiên cao, không cho vận chuyển tính năng mới, đặc biệt ghi đè lớn với những thay đổi đột phá (được gắn với những thay đổi lớn về trình biên dịch).

Các phiên bản chính như Visual C++ 2013 cho chúng ta sự tự do thay đổi và chia nhỏ nhiều nội dung. Đơn giản là không có cách nào để chúng tôi có thể gửi những thứ này trong Bản cập nhật.

Q5: Điều gì về các sửa lỗi? Chúng ta có thể lấy chúng trong một bản cập nhật không?

A5: Đây là một câu hỏi thú vị vì câu trả lời phụ thuộc vào lựa chọn của tôi (trong khi ở câu hỏi trước, tôi sẽ không được phép viết lại bản cập nhật ngay cả khi tôi muốn).

Mỗi nhóm sẽ chọn những bản sửa lỗi nào họ thực hiện cho "nhà máy" để xem xét đưa vào Bản cập nhật. Có những thứ mà xưởng tàu sẽ không cho phép chúng tôi tránh xa (ví dụ: thay đổi vi phạm nhị phân bị cấm bên ngoài các phiên bản chính), nhưng nếu không chúng tôi sẽ có vĩ độ để quyết định mọi thứ. Cá nhân tôi ưu tiên băng thông theo độ trễ - tức là, tôi muốn gửi tổng số bản sửa lỗi lớn hơn trong mọi phiên bản chính, thay vì vận chuyển tổng số lần sửa lỗi ít hơn (trong cùng khoảng thời gian) trong nhiều Cập nhật.

Answer 2

Stephan T. Lavavej, một tác giả chính của thực hiện STL Visual C++ 's đặt ra các quy tắc trong Reddit thread này:

Dưới đây là các quy tắc chính xác:

Nếu bạn bao gồm bất kỳ tiêu đề C thư viện chuẩn ++, bạn phải chơi theo các quy tắc của nó, và chúng tôi cố tình phá vỡ khả năng tương thích nhị phân giữa các phiên bản chính (nhưng giữ nguyên nó giữa các hotfix và các gói dịch vụ). Bất kỳ thay đổi biểu diễn nào (bao gồm nhưng không giới hạn thêm/xóa dữ liệu thành viên) phá vỡ tính tương thích nhị phân, đó là lý do tại sao điều này luôn xảy ra và tại sao chúng tôi ghen tị bảo vệ quyền này.

[snip]

Vì vậy, nếu bạn đang chơi bởi các quy tắc của STL, bạn cần phải đảm bảo những điều sau đây:

• Tất cả các file đối tượng và thư viện tĩnh liên kết thành một nhị phân đơn (EXE/DLL) phải được biên dịch với cùng một phiên bản chính. Chúng tôi đã thêm kiểm tra liên kết để các phiên bản chính của VS 2010+ không kích hoạt lỗi nghiêm trọng vào thời gian liên kết, nhưng nếu VS 2008 hoặc phiên bản cũ hơn thì chúng tôi không thể giúp bạn (không có máy thời gian). Vì ODR áp dụng ở đây, bạn thực sự nên sử dụng cùng một bộ công cụ (tức là cùng một mức gói dịch vụ) cho tất cả các tệp đối tượng và các thư viện tĩnh. Ví dụ, chúng tôi đã khắc phục lỗi std :: string memory giữa VS 2010 RTM và SP1, nhưng nếu bạn trộn RTM và SP1, kết quả nhị phân có thể hoặc không bị ảnh hưởng bởi sự rò rỉ. (Ngoài ra, bạn cần phải sử dụng cùng một cài đặt _ITERATOR_DEBUG_LEVEL và phát hành/gỡ lỗi; chúng tôi có trình kiểm tra liên kết cho những điều này ngay bây giờ.)
• Nếu bạn có nhiều tệp nhị phân được nạp vào cùng một quy trình và chúng vượt qua các đối tượng Thư viện chuẩn C++. , những tệp nhị phân đó phải được xây dựng với cùng phiên bản chính và cài đặt _ITERATOR_DEBUG_LEVEL (bản phát hành/gỡ lỗi cũng phải khớp, tôi quên nếu bạn có thể thoát khỏi sự không khớp ở đây). Quan trọng hơn, chúng tôi không thể phát hiện vi phạm quy tắc này, do đó bạn có thể thực hiện theo quy tắc này.
• Nhiều nhị phân có giao diện thuần túy là C hoặc COM (hoặc bây giờ là WinRT) có thể sử dụng nội bộ các phiên bản chính khác nhau, vì những thứ đó đảm bảo khả năng tương thích nhị phân. Nếu các giao diện của bạn liên quan đến ngôn ngữ C++ Core (ví dụ: các công cụ ảo) nhưng cực kỳ cẩn thận để không bao giờ đề cập đến bất kỳ loại thư viện chuẩn nào của C++, thì có lẽ bạn đã ổn - trình biên dịch thực sự cố gắng tránh phá vỡ khả năng tương thích nhị phân.

Lưu ý, tuy nhiên, khi nhiều tệp nhị phân được nạp vào một tiến trình được biên dịch với các phiên bản chính khác nhau, bạn gần như chắc chắn sẽ kết thúc với nhiều CRT được tải vào quy trình của mình.

Điểm mấu chốt - nếu bạn biên dịch mọi thứ một cách nhất quán 100%, bạn không cần phải lo lắng về bất kỳ nội dung nào trong số này.Không chơi trò chơi trộn nếu bạn có thể tránh nó.