Tại sao con trỏ hàm và con trỏ dữ liệu không tương thích trong C / C ++?

Tôi đã đọc rằng chuyển đổi một con trỏ hàm thành một con trỏ dữ liệu và ngược lại hoạt động trên hầu hết các nền tảng nhưng không được đảm bảo để hoạt động. Tại sao điều này là trường hợp? Cả hai không nên đơn giản là địa chỉ vào bộ nhớ chính và do đó tương thích?

Một kiến ​​trúc không phải lưu trữ mã và dữ liệu trong cùng một bộ nhớ. Với kiến ​​trúc Harvard, mã và dữ liệu được lưu trữ trong bộ nhớ hoàn toàn khác nhau. Hầu hết các kiến ​​trúc là các kiến ​​trúc Von Neumann với mã và dữ liệu trong cùng một bộ nhớ nhưng C không giới hạn bản thân chỉ một số loại kiến ​​trúc nhất định nếu có thể.

Một số máy tính có (có) không gian địa chỉ riêng cho mã và dữ liệu. Trên phần cứng như vậy, nó không hoạt động.

Ngôn ngữ được thiết kế không chỉ cho các ứng dụng máy tính để bàn hiện tại mà còn cho phép nó được thực hiện trên một bộ phần cứng lớn.

Có vẻ như ủy ban ngôn ngữ C không bao giờ có ý định void*trở thành một con trỏ hoạt động, họ chỉ muốn một con trỏ chung cho các đối tượng.

Cơ sở lý luận C99 nói:

6.3.2.3 Con trỏ
C hiện đã được triển khai trên một loạt các kiến ​​trúc. Trong khi một số kiến ​​trúc này có các con trỏ thống nhất có kích thước của một số loại số nguyên, mã di động tối đa không thể có bất kỳ sự tương ứng cần thiết nào giữa các loại con trỏ khác nhau và các loại số nguyên. Trên một số triển khai, con trỏ thậm chí có thể rộng hơn bất kỳ loại số nguyên nào.

Việc sử dụng void*(con trỏ con trỏ đến tên lửa void) làm kiểu con trỏ đối tượng chung là một phát minh của Ủy ban C89. Việc chấp nhận loại này được kích thích bởi mong muốn chỉ định các đối số nguyên mẫu hàm có thể chuyển đổi lặng lẽ các con trỏ tùy ý (như trong fread) hoặc khiếu nại nếu loại đối số không khớp chính xác (như trong strcmp). Không có gì được nói về con trỏ tới các hàm, có thể không tương thích với các con trỏ đối tượng và / hoặc số nguyên.

Lưu ý Không có gì được nói về con trỏ đến các chức năng trong đoạn cuối. Chúng có thể khác với các con trỏ khác, và ủy ban nhận thức được điều đó.

Đối với những người nhớ MS-DOS, Windows 3.1 trở lên, câu trả lời khá dễ dàng. Tất cả những thứ này được sử dụng để hỗ trợ một số mô hình bộ nhớ khác nhau, với sự kết hợp các đặc điểm khác nhau cho mã và dữ liệu con trỏ.

Vì vậy, ví dụ cho mô hình Compact (mã nhỏ, dữ liệu lớn):

sizeof(void *) > sizeof(void(*)())

và ngược lại trong mô hình Trung bình (mã lớn, dữ liệu nhỏ):

sizeof(void *) < sizeof(void(*)())

Trong trường hợp này, bạn không có bộ lưu trữ riêng cho mã và ngày nhưng vẫn không thể chuyển đổi giữa hai con trỏ (không sử dụng công cụ sửa đổi __near và __far không chuẩn).

Ngoài ra, không có gì đảm bảo rằng ngay cả khi các con trỏ có cùng kích thước, chúng chỉ đến cùng một thứ - trong mô hình bộ nhớ nhỏ của DOS, cả mã và dữ liệu được sử dụng gần các con trỏ, nhưng chúng chỉ vào các phân đoạn khác nhau. Vì vậy, chuyển đổi một con trỏ hàm thành một con trỏ dữ liệu sẽ không cung cấp cho bạn một con trỏ có bất kỳ mối quan hệ nào với hàm đó và do đó không có cách sử dụng cho chuyển đổi như vậy.

Các con trỏ tới void được cho là có thể chứa một con trỏ tới bất kỳ loại dữ liệu nào - nhưng không nhất thiết phải là một con trỏ tới một hàm. Một số hệ thống có các yêu cầu khác nhau về con trỏ đến chức năng so với con trỏ tới dữ liệu (ví dụ: có DSP với địa chỉ khác nhau cho dữ liệu so với mã, mô hình trung bình trên MS-DOS sử dụng con trỏ 32 bit cho mã nhưng chỉ con trỏ 16 bit cho dữ liệu) .

Ngoài những gì đã được nói ở đây, thật thú vị khi xem POSIX dlsym():

Tiêu chuẩn ISO C không yêu cầu các con trỏ tới các chức năng có thể được truyền qua lại cho các con trỏ tới dữ liệu. Thật vậy, tiêu chuẩn ISO C không yêu cầu một đối tượng có kiểu void * có thể giữ một con trỏ tới một hàm. Tuy nhiên, các triển khai hỗ trợ phần mở rộng XSI yêu cầu một đối tượng có kiểu void * có thể giữ một con trỏ tới một hàm. Tuy nhiên, kết quả của việc chuyển đổi một con trỏ thành một hàm thành một con trỏ sang một kiểu dữ liệu khác (trừ void *) vẫn chưa được xác định. Lưu ý rằng các trình biên dịch tuân theo tiêu chuẩn ISO C được yêu cầu để tạo cảnh báo nếu việc chuyển đổi từ con trỏ void * sang con trỏ hàm được thử như trong:

 fptr = (int (*)(int))dlsym(handle, "my_function");

Do vấn đề được lưu ý ở đây, một phiên bản trong tương lai có thể thêm một hàm mới để trả về các con trỏ hàm hoặc giao diện hiện tại có thể không được dùng để sử dụng hai hàm mới: một hàm trả về các con trỏ dữ liệu và một hàm khác trả về các con trỏ hàm.

C ++ 11 có một giải pháp cho sự không phù hợp lâu dài giữa C / C ++ và POSIX liên quan đến dlsym(). Người ta có thể sử dụng reinterpret_castđể chuyển đổi một con trỏ hàm thành / từ một con trỏ dữ liệu miễn là việc triển khai hỗ trợ tính năng này.

Từ tiêu chuẩn, 5.2.10 para. 8, "chuyển đổi một con trỏ hàm thành một loại con trỏ đối tượng hoặc ngược lại được hỗ trợ có điều kiện." 1.3.5 định nghĩa "được hỗ trợ có điều kiện" là "chương trình xây dựng mà việc triển khai không bắt buộc phải hỗ trợ".

Tùy thuộc vào kiến ​​trúc đích, mã và dữ liệu có thể được lưu trữ trong các vùng bộ nhớ riêng biệt không tương thích về mặt vật lý.

không xác định không nhất thiết có nghĩa là không được phép, điều đó có thể có nghĩa là người triển khai trình biên dịch có nhiều tự do hơn để làm điều đó theo cách họ muốn.

Chẳng hạn, một số kiến ​​trúc có thể không khả thi - không xác định cho phép họ vẫn có thư viện 'C' phù hợp ngay cả khi bạn không thể làm điều này.

Giải pháp khác:

Giả sử POSIX đảm bảo chức năng và con trỏ dữ liệu có cùng kích thước và biểu diễn (tôi không thể tìm thấy văn bản cho điều này, nhưng ví dụ OP trích dẫn cho thấy ít nhất họ dự định thực hiện yêu cầu này), nên làm như sau:

double (*cosine)(double);
void *tmp;
handle = dlopen("libm.so", RTLD_LAZY);
tmp = dlsym(handle, "cos");
memcpy(&cosine, &tmp, sizeof cosine);

Điều này tránh vi phạm các quy tắc răng cưa bằng cách đi qua char []biểu diễn, được phép đặt bí danh tất cả các loại.

Một cách tiếp cận khác:

union {
    double (*fptr)(double);
    void *dptr;
} u;
u.dptr = dlsym(handle, "cos");
cosine = u.fptr;

Nhưng tôi muốn giới thiệu memcpycách tiếp cận nếu bạn muốn hoàn toàn chính xác 100% C.

Chúng có thể là các loại khác nhau với các yêu cầu không gian khác nhau. Việc gán cho người ta có thể cắt ngang giá trị của con trỏ để gán lại kết quả trong một cái gì đó khác nhau.

Tôi tin rằng chúng có thể là các loại khác nhau vì tiêu chuẩn không muốn giới hạn các triển khai có thể giúp tiết kiệm không gian khi không cần thiết hoặc khi kích thước có thể khiến CPU phải sử dụng thêm crap để sử dụng nó, v.v ...

Giải pháp thực sự di động duy nhất là không sử dụng dlsymcho các chức năng, và thay vào đó sử dụng dlsymđể có được một con trỏ tới dữ liệu có chứa các con trỏ hàm. Ví dụ: trong thư viện của bạn:

struct module foo_module = {
    .create = create_func,
    .destroy = destroy_func,
    .write = write_func,
    /* ... */
};

và sau đó trong ứng dụng của bạn:

struct module *foo = dlsym(handle, "foo_module");
foo->create(/*...*/);
/* ... */

Ngẫu nhiên, dù sao đây cũng là một thực hành thiết kế tốt và giúp dễ dàng hỗ trợ cả tải động qua dlopenvà liên kết tĩnh tất cả các mô-đun trên các hệ thống không hỗ trợ liên kết động hoặc nơi tích hợp người dùng / hệ thống không muốn sử dụng liên kết động.

Một ví dụ hiện đại về nơi con trỏ hàm có thể khác nhau về kích thước so với con trỏ dữ liệu: con trỏ hàm thành viên lớp C ++

Trích dẫn trực tiếp từ https://bloss.msdn.microsoft.com/oldnewthing/20040209-00/?p=40713/

class Base1 { int b1; void Base1Method(); };
class Base2 { int b2; void Base2Method(); };
class Derived : public Base1, Base2 { int d; void DerivedMethod(); };

Bây giờ có hai thiscon trỏ có thể .

Một con trỏ tới hàm thành viên Base1có thể được sử dụng làm con trỏ tới hàm thành viên Derived, vì cả hai đều sử dụng cùng một this con trỏ. Nhưng một con trỏ tới hàm thành viên Base2không thể được sử dụng như là một con trỏ tới hàm thành viên của Derived, vì this con trỏ cần phải được điều chỉnh.

Có nhiều cách để giải quyết điều này. Đây là cách trình biên dịch Visual Studio quyết định xử lý nó:

Một con trỏ tới một hàm thành viên của một lớp được thừa kế thực sự là một cấu trúc.

[Address of function]
[Adjustor]

Kích thước của hàm con trỏ đến thành viên của một lớp sử dụng nhiều kế thừa là kích thước của một con trỏ cộng với kích thước của a size_t.

tl; dr: Khi sử dụng nhiều kế thừa, một con trỏ tới hàm thành viên có thể (tùy thuộc vào trình biên dịch, phiên bản, kiến ​​trúc, v.v.) thực sự được lưu trữ dưới dạng

struct { 
    void * func;
    size_t offset;
}

mà rõ ràng là lớn hơn a void *.

Trên hầu hết các kiến ​​trúc, con trỏ tới tất cả các loại dữ liệu thông thường có cùng một biểu diễn, do đó, việc truyền giữa các loại con trỏ dữ liệu là không có.

Tuy nhiên, có thể hình dung rằng các con trỏ hàm có thể yêu cầu một đại diện khác, có lẽ chúng lớn hơn các con trỏ khác. Nếu void * có thể giữ các con trỏ hàm, điều này có nghĩa là đại diện của void * sẽ phải có kích thước lớn hơn. Và tất cả các phôi con trỏ dữ liệu đến / từ void * sẽ phải thực hiện bản sao bổ sung này.

Như ai đó đã đề cập, nếu bạn cần điều này, bạn có thể đạt được nó bằng cách sử dụng một liên minh. Nhưng hầu hết việc sử dụng void * chỉ dành cho dữ liệu, do đó, sẽ rất khó để tăng tất cả việc sử dụng bộ nhớ của họ chỉ trong trường hợp con trỏ hàm cần được lưu trữ.

Tôi biết rằng điều này đã không được nhận xét trên kể từ năm 2012, nhưng tôi nghĩ rằng nó sẽ hữu ích để thêm rằng tôi làm quen một kiến trúc có rất gợi ý không phù hợp cho dữ liệu và các chức năng kể từ khi một cuộc gọi trên rằng séc kiến trúc đặc ân và mang thông tin thêm. Không có số lượng đúc sẽ giúp. Đó là Mill .