blocks|key|481377|text|架构不必将代码和数据存储在同一内存中。在哈佛架构中，代码和数据存储在完全不同的内存中。大多数架构都是Von+Neumann架构，代码和数据在同一内存中，但如果可能的话，C语言并不局限于某些类型的架构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|481378|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

An architecture doesn't have to store code and data in the same memory. With a Harvard architecture, code and data are stored in completely different memory. Most architectures are Von Neumann architectures with code and data in the same memory but C doesn't limit itself to only certain types of architectures if at all possible.

blocks|key|481431|text|对于那些记得MS-DOS、Windows3.1和更早版本的人来说，答案非常简单。所有这些都用于支持几种不同的内存模型，代码和数据指针的特征组合各不相同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|481432|例如，对于紧凑模型(小代码，大数据)：|481433|sizeof(void+*)+>+sizeof(void(*)())|code-block|syntax|javascript|481434|相反，在中型模型(大代码，小数据)中：|481435|sizeof(void+*)+<+sizeof(void(*)())|481436|在这种情况下，您没有单独存储代码和日期，但仍然无法在两个指针之间进行转换(除非使用非标准的__near和__far修饰符)。|481437|此外，即使指针大小相同，也不能保证它们指向相同的东西-在DOS小内存模型中，代码和数据都在指针附近使用，但它们指向不同的段。因此，将函数指针转换为数据指针根本不会给出与函数有任何关系的指针，因此这样的转换没有任何用处。|481438|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

For those who remember MS-DOS, Windows 3.1 and older the answer is quite easy. All of these used to support several different memory models, with varying combinations of characteristics for code and data pointers.

So for instance for the Compact model (small code, large data):

<pre><code>sizeof(void *) &gt; sizeof(void(*)())
</code></pre>

and conversely in the Medium model (large code, small data):

<pre><code>sizeof(void *) &lt; sizeof(void(*)())
</code></pre>

In this case you didn't have separate storage for code and date but still couldn't convert between the two pointers (short of using non-standard __near and __far modifiers).

Additionally there's no guarantee that even if the pointers are the same size, that they point to the same thing - in the DOS Small memory model, both code and data used near pointers, but they pointed to different segments. So converting a function pointer to a data pointer wouldn't give you a pointer that had any relationship to the function at all, and hence there was no use for such a conversion.

blocks|key|481127|text|指向void的指针应该能够容纳指向任何类型数据的指针--但不一定是指向函数的指针。有些系统对函数指针的要求与对数据指针的要求不同(例如，有些DSP对数据和代码的寻址不同，MS-DOS上的medium型号对代码使用32位指针，但只对数据使用16位指针)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|481128|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Pointers to void are supposed to be able to accommodate a pointer to any kind of data -- but not necessarily a pointer to a function. Some systems have different requirements for pointers to functions than pointers to data (e.g, there are DSPs with different addressing for data vs. code, medium model on MS-DOS used 32-bit pointers for code but only 16-bit pointers for data).

blocks|key|264552|text|在dlsym()方面，C%2B%2B11解决了C/C%2B%2B和POSIX之间长期不匹配的问题。只要实现支持此功能，就可以使用reinterpret_cast将函数指针转换为数据指针，或者将函数指针转换为数据指针。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|264553|根据标准5.2.10第8段，“有条件地支持将函数指针转换为对象指针类型，反之亦然”。1.3.5将“有条件地支持”定义为“实现不需要支持的程序构造”。|264554|entityMap^0|1|7|1K|G|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

C++11 has a solution to the long-standing mismatch between C/C++ and POSIX with regard to <code>dlsym()</code>. One can use <code>reinterpret_cast</code> to convert a function pointer to/from a data pointer so long as the implementation supports this feature.

From the standard, 5.2.10 para. 8, "converting a function pointer to an object pointer type or vice versa is conditionally-supported." 1.3.5 defines "conditionally-supported" as a "program construct that an implementation is not required to support".

blocks|key|481049|text|根据目标架构的不同，代码和数据可能存储在根本不兼容、物理上不同的内存区域中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|481050|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Depending on the target architecture, code and data may be stored in fundamentally incompatible, physically distinct areas of memory.

blocks|key|481170|text|未定义并不一定意味着不允许，它可以意味着编译器实现者有更多的自由来做他们想做的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|481171|例如，这在一些架构上可能是不可能的-未定义允许它们仍然拥有一个符合'C‘库，即使你不能这样做。|481172|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

undefined doesn't necessarily mean not allowed, it can mean that the compiler implementor has more freedom to do it how they want.

For instance it may not be possible on some architectures - undefined allows them to still have a conforming 'C' library even if you can't do this.

blocks|key|264376|text|它们可以是具有不同空间要求的不同类型。赋值给一个可以不可逆地对指针的值进行切片，因此重新赋值会产生不同的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|264377|我相信它们可以是不同的类型，因为该标准不想限制可能的实现，以便在不需要时节省空间，或者当大小可能导致CPU不得不做额外的垃圾来使用它时，等等。|264378|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

They can be different types with different space requirements. Assigning to one can irreversibly slice the value of the pointer so that assigning back results in something different.

I believe they can be different types because the standard doesn't want to limit possible implementations that save space when it's not needed or when the size could cause the CPU to have to do extra crap to use it, etc...

blocks|key|481251|text|唯一真正可移植的解决方案不是对函数使用dlsym，而是使用dlsym来获取指向包含函数指针的数据的指针。例如，在您的库中：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|481252|struct+module+foo_module+=+{
++++.create+=+create_func,
++++.destroy+=+destroy_func,
++++.write+=+write_func,
++++/*+...+*/
};|code-block|syntax|javascript|481253|然后在你的应用程序中：|481254|struct+module+*foo+=+dlsym(handle,+"foo_module");
foo->create(/*...*/);
/*+...+*/|481255|顺便说一句，这是一种很好的设计实践，可以很容易地支持通过dlopen动态加载和静态链接不支持动态链接的系统上的所有模块，或者用户/系统集成商不想使用动态链接的系统。|481256|entityMap^0|J|5|T|5|0|0|0|0|S|6|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|Y|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|Z|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|R|$]]

The only truly portable solution is not to use <code>dlsym</code> for functions, and instead use <code>dlsym</code> to obtain a pointer to data that contains function pointers. For example, in your library:

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

and then in your application:

<pre><code>struct module *foo = dlsym(handle, "foo_module");
foo-&gt;create(/*...*/);
/* ... */
</code></pre>

Incidentally, this is good design practice anyway, and makes it easy to support both dynamic loading via <code>dlopen</code> and static linking all modules on systems that don't support dynamic linking, or where the user/system integrator does not want to use dynamic linking.

blocks|key|481546|text|在大多数架构上，指向所有普通数据类型的指针都具有相同的表示形式，因此在数据指针类型之间进行强制转换是不可行的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|481547|然而，可以想象函数指针可能需要不同的表示，也许它们比其他指针更大。如果void*可以容纳函数指针，这意味着void*的表示必须是较大的大小，并且所有去往void*的数据指针的强制转换都必须执行额外的复制。|481548|正如有人提到的，如果你需要它，你可以使用一个联合来实现它。但是，void*的大多数用法都是针对数据的，因此在需要存储函数指针的情况下，增加它们的所有内存使用量将是非常繁重的。|481549|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

On most architectures, pointers to all normal data types have the same representation, so casting between data pointer types is a no-op.

However, it's conceivable that function pointers might require a different representation, perhaps they're larger than other pointers. If void* could hold function pointers, this would mean that void*'s representation would have to be the larger size. And all casts of data pointers to/from void* would have to perform this extra copy.

As someone mentioned, if you need this you can achieve it using a union. But most uses of void* are just for data, so it would be onerous to increase all their memory use just in case a function pointer needs to be stored.

I have read that converting a function pointer to a data pointer and vice versa works on most platforms but is not guaranteed to work. Why is this the case? Shouldn't both be simply addresses into main memory and therefore be compatible?

Why are function pointers and data pointers incompatible in C/C++?

数据存储

大数据

编译器

我读到过将函数指针转换为数据指针，反之亦然，这在大多数平台上都有效，但并不能保证有效。为什么会这样呢？两者不应该都是简单的地址到主存中，因此是兼容的吗？

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

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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