为什么在C / C ++中函数指针和数据指针不兼容？

我已经读过，在大多数平台上都可以将函数指针转换为数据指针，反之亦然，但不能保证能正常工作。为什么会这样呢？难道两个都不都是简单地寻址到主存储器并因此兼容吗？

架构不必将代码和数据存储在同一内存中。使用哈佛架构，代码和数据存储在完全不同的内存中。大多数体系结构都是冯·诺依曼体系结构，在同一内存中具有代码和数据，但是C绝不将自身限制为仅某些类型的体系结构。

某些计算机具有（具有）用于代码和数据的单独地址空间。在这样的硬件上，它根本不起作用。

该语言不仅为当前的桌面应用程序设计，而且允许在大量硬件上实现。

似乎C语言委员会从未打算过void*要成为函数的指针，他们只是想要一个指向对象的通用指针。

C99基本原理说：

6.3.2.3指针
C现在已在多种体系结构上实现。尽管其中一些体系结构具有统一的指针，这些指针的大小是某些整数类型的大小，但最大的可移植代码无法假定不同指针类型和整数类型之间的任何必要的对应关系。在某些实现中，指针甚至可以比任何整数类型都宽。

使用void*（“指向的指针void”）作为通用对象指针类型是C89委员会的一项发明。指定函数原型参数的愿望刺激了采用这种类型，该函数要么悄悄地转换任意指针（如fread），要么抱怨参数类型不完全匹配（如strcmp）。关于函数的指针，它什么也没说，这可能与对象指针和/或整数不符。

注意在上一段中没有提到任何有关函数的指针。它们可能与其他指标有所不同，委员会对此有所了解。

对于那些记得MS-DOS，Windows 3.1和更早版本的人，答案很简单。所有这些用于支持几种不同的内存模型，并具有代码和数据指针的特征的不同组合。

因此，例如对于紧凑模型（小代码，大数据）：

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

相反，在中型模型中（大代码，小数据）：

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

在这种情况下，您没有代码和日期的单独存储，但是仍然无法在两个指针之间进行转换（缺少使用非标准的__near和__far修饰符）。

另外，不能保证即使指针大小相同，它们也指向同一事物-在DOS小型内存模型中，代码和数据都在指针附近使用，但它们指向的是不同的段。因此，将函数指针转换为数据指针根本不会给您一个与该函数有任何关系的指针，因此这种转换毫无用处。

指向void的指针应该能够容纳指向任何类型数据的指针-但不一定是指向函数的指针。某些系统对功能的指针的要求与对数据的指针的要求不同（例如，DSP的数据和代码的寻址方式不同，MS-DOS上的中等模型对代码使用32位指针，而对数据仅使用16位指针） 。

除了这里已经说过的内容外，看看POSIX还很有趣dlsym()：

ISO C标准不要求可以将指向函数的指针前后转换为指向数据的指针。确实，ISO C标准并不要求void *类型的对象可以持有指向函数的指针。但是，支持XSI扩展的实现确实要求void *类型的对象可以容纳指向函数的指针。但是，将指向函数的指针转换为指向另一种数据类型（void *除外）的指针的结果仍然不确定。请注意，如果尝试从void *指针转换为函数指针，则需要遵循ISO C标准的编译器生成警告，如下所示：

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

由于此处提到的问题，将来的版本可能添加新函数以返回函数指针，或者不建议使用当前接口，而推荐使用两个新函数：一个返回数据指针，另一个返回函数指针。

C ++ 11解决了C / C ++与POSIX之间长期存在的不匹配问题dlsym()。reinterpret_cast只要实现支持此功能，就可以用于将函数指针与数据指针进行转换。

根据标准，第5.2.10段。在图8中，“有条件地支持将函数指针转换为对象指针类型，反之亦然。” 1.3.5将“有条件支持”定义为“不需要实现支持的程序构造”。

根据目标体系结构，代码和数据可能存储在根本不兼容的，物理上不同的内存区域中。

undefined不一定意味着不允许，它可能意味着编译器实现者有更多的自由来按照自己的意愿进行操作。

例如，在某些架构上可能是不可能的-未定义允许它们仍然具有一致的“ C”库，即使您不能这样做也是如此。

另一个解决方案：

假设POSIX保证函数和数据指针具有相同的大小和表示形式（我找不到用于此的文本，但是引用的示例OP建议它们至少旨在满足此要求），以下应该起作用：

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

这样可以避免通过遍历char []表示形式而违反别名规则，该表示形式允许别名所有类型。

另一种方法：

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

但是memcpy如果您绝对希望100％正确的C语言，我会推荐这种方法。

它们可以是具有不同空间要求的不同类型。分配给一个指针可以不可逆地对指针的值进行切片，因此向后分配将产生不同的结果。

我相信它们可以是不同的类型，因为该标准不想限制可能的实现，这些实现可以在不需要时或节省空间的情况下节省空间，而这种大小可能导致CPU必须做更多操作才能使用它，等等。

唯一真正可移植的解决方案是不dlsym用于函数，而用于dlsym获取指向包含函数指针的数据的指针。例如，在您的库中：

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

然后在您的应用程序中：

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

顺便说一句，无论如何，这都是好的设计实践，并且可以轻松地通过dlopen不支持动态链接或用户/系统集成商不希望使用动态链接的系统上的所有模块通过静态链接来支持动态加载。

一个现代的示例，其中函数指针的大小可以与数据指针的大小不同：C ++类成员函数指针

直接引自https://blogs.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(); };

现在有两个可能的this指针。

指向的成员函数的Base1指针可用作指向的成员函数的指针Derived，因为它们都使用相同的this 指针。但是指向的成员函数的指针Base2不能原样用作指向的成员函数Derived的this 指针，因为该指针需要调整。

有许多解决方法。这是Visual Studio编译器决定处理它的方式：

指向多重继承类的成员函数的指针实际上是一个结构。

[Address of function]
[Adjustor]

使用多重继承的类的指向成员函数的指针的大小是指针的大小加上a的大小size_t。

tl; dr：使用多重继承时，指向成员函数的指针（取决于编译器，版本，体系结构等）实际上可以存储为

struct { 
    void * func;
    size_t offset;
}

显然比void *。

在大多数体系结构上，指向所有普通数据类型的指针具有相同的表示形式，因此在数据指针类型之间进行强制转换是不可操作的。

但是，可以想到的是，函数指针可能需要不同的表示形式，也许它们比其他指针更大。如果void *可以容纳函数指针，则意味着void *的表示形式必须更大。并且所有向/从void *进行数据指针的强制转换都必须执行此额外复制。

如某人所述，如果您需要此功能，则可以使用联合来实现。但是void *的大多数用法只是用于数据，因此，以防万一需要存储函数指针，增加它们的所有内存使用量将是繁重的工作。

我知道自2012年以来就没有对此进行评论，但是我想补充一下，我确实知道一个体系结构具有非常不兼容的数据和功能指针的指针，这很有用，因为对该体系结构的调用会检查特权并携带额外的信息。大量的投放都无济于事。是磨坊。