Liên kết cấu trúc C++ x86/x64 + Sử dụng thư viện .NET AnyCPU C++ (gọi/gọi lại)

Question

Câu hỏi trước của tôi không thành công ("C# Thư viện AnyCPU sử dụng API x86/x64 C - cấu trúc đóng gói, cuộc gọi và gọi lại") , Tôi sẽ viết một cái ngắn gọn và trừu tượng hơn.

CÁC HÌNH ẢNH:

Công ty nơi tôi làm việc có một phần mềm để được chuyển về 64 bit. Phần mềm bao gồm một thư viện BASE (C++ với C API) một hai trình bao bọc trên C API: một trình bao bọc C++ và một trình bao bọc .NET.

Thư viện C + + BASE & C++ WRAPPER phải có cấu hình xây dựng x86/x64. .NET WRAPPER chỉ có cấu hình xây dựng AnyCPU.

Chọn đúng thư viện từ .NET WRAPPER đã được hoàn tất thành công (cả hai thư viện C++ BASE (x86/x64) đang được nạp vào hai không gian tên riêng biệt và tùy thuộc vào kích thước của IntPtr các hàm bên phải được gọi là thời gian chạy; không nhất thiết yêu cầu cả hai thư viện ở đó, nhưng chỉ có một thư viện được sử dụng).

CÁC VẤN ĐỀ:

Tất cả các cấu trúc trong các thư viện cơ sở được xếp trên 4 byte:

#pragma pack(push,4) 

Để có mã biên dịch với NO cảnh báo trên 64-bit, tôi có thêm liên kết chọn lọc (C + + BASE & C++ WRAPPER hoạt động như quyến rũ):

#ifdef WIN64 
#pragma pack(push,8) 
#else 
#pragma pack(push,4) 
#endif 

Vấn đề là liên quan đến cấu trúc trong .NET:

[StructLayout(LayoutKind.Sequential, Pack = 4, CharSet = CharSet.Unicode)] 
    internal struct DBConnectionSettings{...} 

Cấu trúc này không thể có bao bì chọn lọc vì AnyCPU là cấu hình WRAPPER chỉ mong muốn.

Rất khó (XẾP HẠNG VÀ MẤT MẤT) để tạo các cấu trúc riêng biệt được căn chỉnh trên 8 byte trong một không gian tên .NET khác nhau ... Tuy nhiên, đây có thể là giải pháp duy nhất mà chúng tôi có thể tìm được.

Giảm trở lại 4 byte đối với cả hai vấn đề x86 và x64 L LOTI cảnh báo vì 100% cấu trúc nhạy cảm với đóng gói, đặc biệt cho các toán tử đơn nhất (sự cố chỉ xuất hiện trên cấu hình giải pháp x64 với căn chỉnh 4 byte). Rất nhiều sự cố, cấu trúc không thể căn chỉnh trừ khi chúng ta thêm các thành viên giả. Tôi nên đề cập rằng cấu trúc được nhóm lại dựa trên ý nghĩa hoặc liên quan đến hệ điều hành cấp phép/đích (ifdefs). Việc thêm thành viên đệm (giả) vào tất cả các khả năng sẽ đòi hỏi hàng tháng.

Căn chỉnh mọi thứ trên 8 byte không phải là giải pháp vì chúng tôi không nhận được sự cố nào nữa - chỉ cho x86, x64 hoạt động tốt - liên kết cấu trúc yêu cầu lại thành viên và nhóm dựa trên kích thước.

CÁC KẾT LUẬN (CÂU HỎI):

1) Có thể cho một mã C++ phải có sự liên kết của 4 cho cả x86 và x64 giải pháp cấu hình? Làm thế nào điều này có thể được thực hiện?

2) Phương án thay thế tốt nhất cho x86 và x64 là gì? Kích thước con trỏ chắc chắn nên cai trị sự liên kết (theo ý kiến ​​của tôi). Chúng tôi đang tìm cách để có phần mềm FAST, không nhất thiết phải bộ nhớ hiệu quả (cho đến nay dấu vân tay bộ nhớ là một nơi nào đó giữa 15mb và 2gb trên x86 hệ thống).

3) Nhu cầu đặc biệt nào có cấu trúc mang con trỏ hàm có liên quan đến interop giữa .NET và C?

4) Bất kỳ giải pháp thay thế được đề xuất nào đều được đánh giá cao.

Chúng tôi đã tìm kiếm hơn một tháng trên internet này (trên hành tinh của chúng tôi) nhưng chúng tôi đã không đi đến đâu cả. Một số kiến ​​trúc sư cầu xin sử dụng đóng gói có chọn lọc (4/8) trong khi một số người cho rằng phần mềm không thẳng về phía trước và nó nên được tái cấu trúc. Nó không phải là quyết định của tôi phải làm gì, nhưng tôi có thể mang lại những ý tưởng với những lý lẽ tốt. Phần mềm này đã được bắt đầu vào cuối năm 2000, khi STL bị lỗi, vì vậy BASE có các thùng chứa riêng của nó được tối ưu hóa cho Thiên Chúa-biết-những gì. Tôi không nên bày tỏ ý kiến ​​của tôi ở đây vì nó không phải là Cơ đốc nhân.

Answer 1

Chỉ cần sửa vấn đề căn chỉnh ở phía C++. Không nên có lý do cho mã x86 bị ​​hỏng khi căn chỉnh 8 byte, cũng như không cho x64 gặp sự cố liên kết 4 byte. #pragma pack(push,4) sẽ là phương pháp phù hợp. Bạn có thể cần một mã khác #pragma pack cho mã SSE nội bộ, nhưng mã đó không được hiển thị với mã. AnyCPU.

Nếu bạn nhận được hàng trăm cảnh báo (bỏ qua cảnh báo hoàn hảo), thì trình biên dịch đồng ý với đánh giá của tôi rằng mã của bạn là nghi ngờ.