C’est bien que les gens manifestent leurs opinions et je pense d’ailleurs que l’on veut tous dire la meme chose.
Je crois sincèrement que la phrase proposée pour le doc recoupe parfaitement les propos de Denis. Je souhaite simplement qu’elle soit suffisamment concise et claire. Le dernier mot restera cela de Fred quoi qu’il en soit.
Voila donc mon explication de texte :
Nous sommes d’accord pour dire qu’un pointeur représente une adresse.
Prenons une compilation 32 bits, on peut dire alors qu’il y a équivalence entre *Pointeur et ‘*Pointeur.l’ Par conséquent le pointeur à un type long.
C’est actuellement le cas en PB qui n’offre que ce mode de compilation
Prenons maintenant une compilation 64 bits, on peut dire cette fois qu’il y a équivalence entre *Pointeur et ‘*Pointeur.q’.
Par conséquent le pointeur à un type quad
Donc un pointeur a bien un type, soit long soit quad selon s’il s’agit d’une compilation 32 ou 64 bits (on peut meme en imaginer d’autre comme .b ou .w, arriéré mais tout à fait possible…
).
Mais puisque justement le type d’un pointeur varie en fonction du mode de compilation et/ou de la capacité d’adressage du processeur on ne peut pas parler directement de long ou de quad.
C’est pour cela que l’on doit parler d’un type différence : le type pointeur.
C’est quoi le type pointeur ? C’est le type courant (long, quad ou autre) qui permet de représenter une adresse en mémoire selon le mode de compilation et la capacité d’adressage du processeur.
Obliger d’imposer un type prédéfinie à un pointeur n’est pas possible par essence et PB ne le permet pas (sauf problème avec un string, mais c’est déjà signalé)
C’est exactement le sens de la phrase :
C’est pour cette raison qu’un pointeur est une variable dite de type pointeur car son encombrement en mémoire sera lié à la capacité d’adressage mémoire du processeur.
Il en découle qu’affecter un type à un pointeur (*Pointeur.l, *Pointeur.b…) n’a aucun sens puisque l’encombrement mémoire d’un pointeur est imposé par celui d’une adresse et non par celui d’un type.
Aussi, on obtiendra bien le meme résultat si on remplace dans l’exemple de code donné par Comtois les « *Ptr » par des long : « Ptr.l ». Cela signifie simplement que la compilation est 32 bits.
Maintenant, si PB laisse faire le typage d’un pointeur, c'est un autre problème (je rappeles qu’il ignore tout typage). Je suis d’accord pour que cela soit supprimé.
Mais on comprend tous pourquoi c'est toléré par le compilateur: on construit un pointeur sur la base d’une variable car c’est une variable.
C’est pour cela qu’il est important que la doc lève le problème et je suis confiant qu'en à l’évolution de PB.
Enfin, la notion de type et de structure est confuse au départ (j’associais d’ailleurs les deux au tout début).
Pourtant l’un est l’autre ne peuvent pas cœxister: une variable est soit typé, soit structurée.
Cette ambiguïté tient à mon sens à deux points :
- le manque d’explication et/ou l’inexpérience du programmeur
- le mimétisme entre les deux notions : les memes noms sont utilisés ainsi que le même mécanisme d’attribution à une variable (à savoir l’opérateur ‘.’) se qui contribue à entretenir la confusion:
a.l est une variable typée long: ‘Debug a’ retourne le chiffre long contenu en @a
a.Long est une variable structurée Long: ‘Debug a’ retourne @a. Il faut écrire 'Debug a\l' pour accéder au chiffre long contenue en @a.
Cependant, il n’y a pas d’ambiguïté, simplement un concept à bien saisir.
