2015-11-27 17 views
13

Tôi có một ứng dụng với các đối tượng STL được sử dụng như một phần của giao diện C++ cho các trình soạn thảo trình cắm thêm.Khả năng tương thích GCC của các thư viện được chia sẻ với các đối tượng STL trong giao diện của chúng

Tôi biết tùy chọn tốt nhất cho khả năng tương thích sẽ là sử dụng giao diện C thay vào đó, nhưng điều đó hiện không khả thi.

Tôi biết rằng mọi thứ từ GCC 3.4 đến 4.8 trong libstdC++ đều tương thích cao về ABI. Vì vậy, ví dụ, nếu tôi biên dịch với GCC 4.1, và một nhà cung cấp plug-in viết mã được biên dịch với GCC 4.7, thì các trường hợp chặn góc sẽ tốt trên một nền tảng với phiên bản libstdC++ tương ứng với GCC 4.7 hoặc mới hơn, cung cấp STL useage là nội bộ cho .so chỉ, và rằng giao diện bên ngoài .so đang sử dụng tinh khiết C, mà đáng buồn là không phải là trường hợp đối với tôi.

Vì vậy, tôi rất tò mò về trường hợp sẽ liên quan đến các lớp STL được sử dụng như một phần của giao diện trình cắm thêm. Tôi có thể an toàn vượt qua các đối tượng STL giữa các đối tượng được chia sẻ không được biên dịch cùng phiên bản trình biên dịch (ví dụ: 4.1 và 4.8) không? Và có bất cứ điều gì tôi cần phải được lưu tâm liên quan đến cách các mẫu được biên dịch và giải quyết nếu mọi người sử dụng các tùy chọn trình biên dịch khác nhau?

Tôi nghi ngờ nó sẽ có vấn đề. Tuy nhiên, có một cơ hội biểu tượng ma thuật phiên bản được thực hiện bởi các folks GCC bằng cách nào đó có thể làm cho công việc này.

Đối với câu hỏi này, tôi chỉ quan tâm đến việc biên dịch và liên kết trước C++ 11. Tôi cũng chỉ quan tâm đến Linux và Mac OS X, sử dụng GCC.

+1

Trừ khi mọi người đang đi ra khỏi con đường của họ để làm cho nó thất bại, nó sẽ làm việc tốt. –

+0

@marc Cảm ơn bạn đã phản hồi. Bất kỳ cơ hội bạn có thể cung cấp một tài liệu tham khảo hoặc một liên kết mà đi vào điều này trong một chút chi tiết hơn (hoặc có lẽ các dự án dựa vào điều này)? – Rob

+1

Nó sẽ không nhất thiết phải hoạt động, mặc dù, đối với gcc> = 5.0, vì chúng [đã thay đổi ABI] của chúng (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html) – Walter

Trả lời

7

Tôi đã trả lời câu hỏi này trên mailing list nhưng như Marc đã nói, nó sẽ chỉ hoạt động.

Nó không tạo ra sự khác biệt cho dù bạn sử dụng thư viện nội bộ cho DSO hay trong giao diện, thư viện không quan tâm và tương thích ngược với GCC 3.4 một trong hai cách.

+0

Rất cám ơn câu trả lời! Tôi sẽ chấp nhận nó, bởi vì bạn là một thẩm quyền trên libstdC++. Như đã đề cập trong danh sách gửi thư, nếu có bất kỳ tài liệu nào bạn có thể chỉ cho tôi về cách bạn đạt được mức độ tương thích cao ABI (ví dụ: đảm bảo bố cục bộ nhớ vẫn nhất quán, nội tuyến vẫn phù hợp, v.v.), thì Tôi đánh giá cao nó. – Rob

+0

@Jonathan Wakely Nếu bạn nhận được một kịch bản mà mới/malloc được thực hiện bên trong lib, con trỏ bằng cách nào đó tuyên truyền cho ứng dụng của người dùng và xóa/miễn phí được thực hiện ở đó? Tôi đã thấy các tình huống trong đó có nhiều hơn một phiên bản libc và nhiều hơn một bộ cấp phát bộ nhớ trong cùng một ứng dụng, và kịch bản trên có thể khiến ứng dụng gặp sự cố. –

+0

@ ErikAlapää, có nhiều hơn một libc là vấn đề của bạn, không phải vấn đề của libstdC++. Tiêu chuẩn nói rằng các hàm phân bổ là toàn cầu, nếu bạn vi phạm Quy tắc Một Định nghĩa bằng cách có nhiều hàm phân bổ không tương thích thì bạn cần phải tự giải quyết nó. –

Các vấn đề liên quan