Có phải C ++ 11 đã giải quyết các vấn đề liên quan đến việc chuyển các đối tượng lib giữa các ranh giới thư viện động / chia sẻ? (tức là dlls và như vậy)?

Một trong những phàn nàn chính của tôi về C ++ là việc thực hành khó khăn như thế nào khi vượt qua các đối tượng thư viện std bên ngoài ranh giới thư viện động (tức là dll / so).

Thư viện std thường chỉ tiêu đề. Đó là tuyệt vời để làm một số tối ưu hóa tuyệt vời. Tuy nhiên, đối với dll, chúng thường được xây dựng với các cài đặt trình biên dịch khác nhau có thể ảnh hưởng đến cấu trúc / mã bên trong của bộ chứa thư viện std. Ví dụ, trong MSVC, một dll có thể được xây dựng với trình gỡ lỗi lặp trong khi một bản dựng khác bị tắt. Hai dll này có thể gặp vấn đề khi chuyển các thùng chứa std xung quanh. Nếu tôi hiển thị std::stringtrong giao diện của mình, tôi không thể đảm bảo mã mà khách hàng đang sử dụng std::stringlà trùng khớp chính xác với thư viện của tôi std::string.

Điều này dẫn đến khó gỡ lỗi, đau đầu, v.v. Bạn có thể kiểm soát chặt chẽ các cài đặt trình biên dịch trong tổ chức của mình để ngăn chặn các sự cố này hoặc bạn sử dụng giao diện C đơn giản hơn sẽ không gặp phải các vấn đề này. Hoặc chỉ định cho khách hàng của bạn các cài đặt trình biên dịch dự kiến ​​mà họ nên sử dụng (sẽ hút nếu thư viện khác chỉ định các cài đặt trình biên dịch khác).

Câu hỏi của tôi là liệu C ++ 11 có cố gắng làm bất cứ điều gì để giải quyết những vấn đề này không?

Bạn đúng rằng mọi thứ STL - thực ra, mọi thứ từ bất kỳ thư viện bên thứ ba nào được tạo khuôn mẫu - tốt nhất nên tránh trong mọi API C ++ công khai. Bạn cũng muốn tuân theo danh sách dài các quy tắc tại http://www.ros.org/reps/rep-0009.html#def định để ngăn chặn sự phá vỡ ABI khiến việc lập trình API C ++ công khai trở thành một việc vặt.

Và câu trả lời liên quan đến C ++ 11 là không, tiêu chuẩn này không chạm vào điều đó. Thú vị hơn là tại sao không? Câu trả lời là bởi vì C ++ 17 rất cảm động về điều đó và để các Mô-đun C ++ được triển khai, chúng ta cần các mẫu đã xuất để hoạt động và để chúng ta cần một trình biên dịch kiểu LLVM như clang có thể đổ AST đầy đủ vào đĩa và sau đó thực hiện tra cứu phụ thuộc vào người gọi để xử lý nhiều trường hợp vi phạm ODR trong bất kỳ dự án C ++ lớn nào - nhân tiện, bao gồm rất nhiều mã GCC và ELF.

Cuối cùng, tôi thấy rất nhiều MSVC ghét và bình luận ủng hộ GCC. Đây là những thông tin rất sai lệch - GCC trên ELF về cơ bản và không thể tin được, không có khả năng tạo mã C ++ hợp lệ và chính xác. Lý do cho điều này rất nhiều và quân đoàn, nhưng tôi sẽ nhanh chóng trích dẫn một ví dụ điển hình: GCC trên ELF không thể tạo ra các phần mở rộng Python được viết bằng Boost.Python trong đó có nhiều hơn một phần mở rộng dựa trên Boost.Python được tải vào Python. Đó là bởi vì ELF với bảng ký hiệu C toàn cầu của nó chỉ đơn giản là không có khả năng bằng cách thiết kế ngăn chặn vi phạm ODR gây ra sự phân tách, trong khi PE và MachO và thực tế là đặc tả Mô-đun C ++ được đề xuất đều sử dụng bảng ký hiệu trên mỗi mô-đun - điều này cũng có nghĩa là thời gian xử lý nhanh hơn rất nhiều. Và còn nhiều vấn đề nữa: hãy xem một StackOverflow tôi đã trả lời gần đây tạihttps://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-rp4-error/14364055#14364055, ví dụ như các cú ném ngoại lệ C ++ bị phá vỡ một cách cơ bản trên ELF.

Điểm cuối cùng: liên quan đến việc xen kẽ các STL khác nhau, đây là một nỗi đau lớn đối với nhiều người dùng doanh nghiệp lớn đang cố gắng trộn các thư viện của bên thứ ba được tích hợp chặt chẽ với một số triển khai STL. Giải pháp duy nhất là một cơ chế mới để C ++ xử lý interop STL, và trong khi chúng ở đó, bạn cũng có thể sửa lỗi trình biên dịch xen kẽ để bạn có thể (ví dụ) trộn các tệp đối tượng được biên dịch MSVC, GCC và clang và tất cả chỉ hoạt động . Tôi sẽ xem nỗ lực của C ++ 17 và xem những gì sẽ xuất hiện trong vài năm tới - Tôi sẽ ngạc nhiên nếu không có gì.

Các đặc điểm kỹ thuật không bao giờ có vấn đề này. Đó là bởi vì nó có khái niệm gọi là "một quy tắc định nghĩa", quy định bắt buộc rằng mỗi biểu tượng có chính xác một định nghĩa trong quy trình đang chạy.

Windows DLL vi phạm yêu cầu này. Đó là lý do tại sao có tất cả những vấn đề này. Vì vậy, tùy thuộc vào Microsoft để sửa nó, không phải ủy ban tiêu chuẩn hóa C ++. Unix không bao giờ gặp vấn đề này, bởi vì các thư viện dùng chung hoạt động khác ở đó và theo mặc định tuân thủ một quy tắc định nghĩa (bạn rõ ràng có thể phá vỡ nó, nhưng rõ ràng bạn chỉ làm nếu bạn biết bạn có đủ khả năng và cần phải loại bỏ vài chu kỳ bổ sung).

Windows DLL vi phạm một quy tắc định nghĩa vì:

• Chúng mã hóa từ thư viện động mà một biểu tượng sẽ được sử dụng trong thời gian liên kết tĩnh và giải quyết các biểu tượng tĩnh trong thư viện xác định chúng. Vì vậy, nếu cùng một biểu tượng yếu được tạo trong nhiều thư viện dùng chung và các thư viện đó được sử dụng trong một quy trình đơn lẻ, thì trình liên kết động không có cơ hội hợp nhất các biểu tượng đó. Thông thường các ký hiệu như vậy là các thành viên tĩnh hoặc trở ngại lớp của các thể hiện khuôn mẫu và nó gây ra vấn đề khi chuyển các thể hiện giữa các mã trong các DLL khác nhau.
• Họ mã hóa cho dù biểu tượng sẽ được nhập từ thư viện động đã trong quá trình biên dịch. Do đó, mã được liên kết với một số thư viện tĩnh không tương thích với mã được liên kết với cùng một thư viện.

Unix sử dụng định dạng xuất ELF nhập ngầm tất cả các ký hiệu đã xuất để tránh sự cố đầu tiên và không phân biệt giữa các ký hiệu được giải quyết tĩnh và động cho đến thời gian liên kết tĩnh để tránh lần thứ hai.

Vấn đề khác là cờ biên dịch. Vấn đề đó tồn tại đối với bất kỳ chương trình nào được soạn từ nhiều đơn vị biên dịch, các thư viện động không phải tham gia. Tuy nhiên, nó tệ hơn nhiều trên Windows. Trên Unix, việc bạn liên kết tĩnh hay động không quan trọng, dù sao đi nữa, không ai liên kết thời gian chạy tiêu chuẩn tĩnh (trong Linux, nó thậm chí có thể là bất hợp pháp) và không có thời gian chạy gỡ lỗi đặc biệt, vì vậy một bản dựng là đủ tốt. Nhưng cách Microsoft triển khai liên kết tĩnh và động, gỡ lỗi và giải phóng thời gian chạy và một số tùy chọn khác có nghĩa là chúng gây ra sự bùng nổ tổ hợp của các biến thể thư viện cần thiết. Một lần nữa vấn đề nền tảng chứ không phải vấn đề ngôn ngữ C ++.

Không.

Có rất nhiều công việc đang diễn ra để thay thế hệ thống tiêu đề, tính năng được gọi là Mô-đun và có thể có tác động đến điều này, nhưng chắc chắn không phải là một vấn đề lớn.