Quelle est la raison d'être de _PTR_?

Je travaille avec une base de source avec un peu clair pour moi se prononcer sur les types de pointeur définition: en utilisant _ PTR _ macro au lieu de *. Ainsi, tous les prototypes de fonction et typedefs ressemblent:Quelle est la raison d'être de _PTR_?

extern FILE_PTR _io_fopen(const char _PTR_, const char _PTR_);

Je me demande ce qui pourrait être la raison derrière cela car, pour moi, cela semble excessif.

EDIT

Par ailleurs, pour le double indirection j'ai trouvé:

_io_strtod(char _PTR_, char _PTR_ _PTR_);

Source

2011-09-19 pmod

Bonne question. Je suis vraiment curieux de voir si quelqu'un a une bonne réponse à celui-ci. Voyez-vous '__PTR__ __PTR__' pour la double indirection aussi? : S –

lol ... peut-être que le programmeur qui a eu cette idée avait des problèmes de vision et de la difficulté à reconnaître les petits astérisques au milieu de tous les autres symboles présents dans un fichier source typique. – pmg

@Michael Mior Ha-ha - il y a :) – pmod

Il est possible que la définition est la compatibilité avec le DOS.

#ifdef DOS 
#define _PTR_ far * 
#else 
#define _PTR_ * 
#endif

Les far/near mots-clés permettent des pointeurs pour traiter la mémoire à l'intérieur/à l'extérieur du segment en cours, ce qui permet des programmes pour traiter plus de 64 Kio de la mémoire tout en conservant les avantages de 16 pointeurs de bits pour un code plus rapide/moins utilisation de la mémoire .

Il est plus courant d'exclure * de la définition. Par exemple, dans LibPNG, vous pouvez voir les définitions comme:

typedef png_color FAR * png_colorp; 
typedef png_color FAR * FAR * png_colorpp;

Sur la plupart des plates-formes, FAR sera #defined à rien.

Bien que DOS soit ancien, certaines architectures embarquées modernes ont des problèmes similaires. Pour les processeurs d'architecture Harvard, les pointeurs vers la mémoire de programme et de données doivent être accédés en utilisant différentes instructions, ils ont donc des types différents. D'autres processeurs ont des «modèles de données» différents, et il n'est pas rare de voir des types de pointeurs spéciaux pour les pointeurs inférieurs à 2^24, 2^16 ou 2^8.

Source

2011-09-19 14:52:10

Eh bien, peut-être, mais ce que je peux voir, c'est qu'il est #define _PTR_ * et dans une partie du code lié à la plate-forme spécifique (le code n'est pas pour construire sous DOS, en fait c'est dans un RTOS). Donc, probablement, ils voulaient garder le code portable pour le futur lointain (ha = ha) ... – pmod

@pmod: De nombreuses architectures embarquées ont différents types de pointeurs, tout comme DOS, ce qui pourrait expliquer cela. –

Je ne pense pas que cette réponse ait du sens. Si vous vouliez que tous les pointeurs soient loin sur DOS, vous utiliseriez le modèle de mémoire grand/grand. Si vous voulez seulement que certains pointeurs soient loin, alors appeler la macro '_PTR_' n'a pas de sens ... –

C'est une bonne convention facilement (pour les définitions suffisamment petites de facilement) la différence entre la multiplication et indirection

int _PTR_ arr = malloc(42 * sizeof _PTR_ arr);

Source

2011-09-19 14:52:44 pmg

Eh, 'int * arr' ne ressemble pas comme la multiplication, D – Griwes

Pas là, @Griwes: dans l'argument malloc! Aussi '42 ** arr' ==' '42 * _PTR_ arr' ==' 42 * arr [0] ' – pmg

C'est pourquoi j'ajoute toujours des espaces dans les lieux appropriés ...' 42 * (* arr) 'ou' 42 * * arr' est plus clair et n'implique pas de macro illisible et majuscule (= moche). Et avec 'sizeof', utilisez juste' 42 * sizeof (* arr) ', si vous avez besoin d'une telle expression ... – Griwes

Quelle est la raison d'être de _PTR_?

Répondre

Questions connexes