Pourquoi les pointeurs de fonction et les pointeurs de données sont-ils incompatibles en C / C ++?

Une architecture n'est pas nécessaire de stocker le code et les données dans la même mémoire. Avec une architecture Harvard, le code et les données sont stockées dans un contexte totalement différent de la mémoire. La plupart des architectures, Von Neumann architectures avec le code et les données dans le même mémoire, mais C ne se limite pas uniquement à certains types d'architectures si possible.

Pour ceux qui se souviennent de MS-DOS, Windows 3.1 et plus la réponse est assez facile. L'ensemble de ces utilisés à l'appui de plusieurs différents modèles de mémoire, avec différentes combinaisons de caractéristiques pour le code et les données des pointeurs.

Ainsi, par exemple, pour le modèle Compact (petit code, de données de grande taille):

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

et, à l'inverse, dans le modèle Moyen (grand code, de données de petite taille):

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

Dans ce cas, vous n'avez pas de stockage séparé pour le code et la date, mais ne pouvait toujours pas de conversion entre les deux pointeurs (court de l'utilisation non-standard __près de et __ _ _ loin de modificateurs).

En outre, il n'y a aucune garantie que même si les pointeurs sont de la même taille, qu'ils pointent vers la même chose dans le DOS Petit modèle de mémoire, à la fois le code et les données utilisées près de pointeurs, mais ils ont souligné les différents segments. Si la conversion d'un pointeur de fonction à un pointeur de données ne serait pas vous donner un pointeur qui ont une relation à la fonction, et il n'y a donc pas d'utilisation d'une telle conversion.

En plus de ce qui est déjà dit ici, il est intéressant de regarder POSIX dlsym():

Le C ISO norme n'exige pas que les pointeurs de fonctions peut être jeté en arrière et en avant pour des pointeurs vers les données. En effet, la norme ISO C standard ne nécessite pas qu'un objet de type void * peut contenir un pointeur à une fonction. Les implémentations de soutenir l'extension XSI, cependant, ne nécessitent qu'un objet de type void * peut contenir un pointeur à une fonction. Le résultat de la conversion d'un pointeur à une fonction en un pointeur vers un autre type de données (à l'exception de void *) n'est toujours pas défini, cependant. Notez que les compilateurs conformes à la norme ISO C standard sont nécessaires pour générer une alerte si une conversion à partir d'un void * pointeur vers un pointeur de fonction est tenté comme dans:

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

À cause du problème de noter ici, une version ultérieure peut soit ajouter une nouvelle fonction pour renvoyer des pointeurs de fonction, ou de l'interface actuelle peut être dépréciée en faveur de deux nouvelles fonctions: l'une qui renvoie les pointeurs de données et l'autre qui renvoie des pointeurs de fonction.

En fonction de l'architecture cible, le code et les données peuvent être stockées dans fondamentalement incompatibles, physiquement distinctes des zones de mémoire.

Ils peuvent être de différents types avec différentes exigences de l'espace. L'attribution à l'un peut de manière irréversible la tranche de la valeur du pointeur de façon à ce que l'affectation de résultats dans quelque chose de différent.

Je crois qu'ils peuvent être de différents types, car la norme ne se limite possible des implémentations d'économiser de l'espace lorsqu'il n'est pas nécessaire, ou lorsque la taille pourrait provoquer le CPU supplémentaires, de la merde pour l'utiliser, etc...

La seule véritable solution portable est de ne pas utiliser dlsym pour les fonctions, et au lieu d'utiliser dlsym pour obtenir un pointeur vers les données qui contient des pointeurs de fonction. Par exemple, dans votre bibliothèque:

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

et puis dans votre application:

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

D'ailleurs, c'est une bonne pratique en matière de conception, de toute façon, et il est facile de soutenir à la fois le chargement dynamique via dlopen et statique de la liaison de tous les modules sur les systèmes qui ne prennent pas en charge la liaison dynamique, ou lorsque l'utilisateur/intégrateur système ne souhaitez pas utiliser la liaison dynamique.

Un exemple moderne d'où des pointeurs de fonction peuvent varier en taille de pointeurs de données: membre de classe C++ pointeurs de fonction

Directement tirée de la 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(); };

Il y a maintenant deux this pointeurs.

Un pointeur vers une fonction membre de Base1 peut être utilisé comme un pointeur vers un
fonction de membre de Derived, car ils utilisent tous les deux le même this
pointeur. Mais un pointeur vers une fonction membre de Base2 ne peut pas être utilisé
en tant qu'un pointeur vers une fonction membre de Derived, depuis le this
pointeur doit être ajusté.

Il existe de nombreuses façons de résoudre ce. Voici comment Visual Studio
compilateur décide de le manipuler:

Un pointeur vers une fonction membre d'une multiplication, héritée de la classe est vraiment
une structure.

[Address of function]
[Adjustor]

La taille d'un pointeur-à-membres de la fonction d'une classe qui utilise l'héritage multiple est de la taille d'un pointeur, plus la taille d'un size_t.

tl;dr: Lors de l'utilisation de l'héritage multiple, un pointeur vers une fonction membre peut (selon le compilateur, la version, l'architecture, etc) en fait être stockées en tant que

struct { 
    void * func;
    size_t offset;
}

ce qui est évidemment plus grand qu'un void *.