Pointeurs de Structure

A l'issue d'un appel vers une API, j'ai une réponse avec un pointeur vers une structure.
J'ai deux syntaxe dans le même code suivant le traitement à faire.

La première syntaxe est :

Code:

---

1 2 3

STRUCTURE_1 *pObjData = (STRUCTURE_1*)pData;

---

Et la deuxième est :

Code:

---

1 2 3

STRUCTURE_1* pObjData = (STRUCTURE_1*)pData;

---

La différence est minime : l'Astérix "*" n'est pas placée au même endroit avant le PobjData. Dans le premier cas, l'Astérix est collé à STRCTURE_1 et dans le deuxième l'Astérix est collé à PobjData.

1/ Est-ce le même résultat dans les deux cas ?

2/ Sachant que le pData est le pointeur d'adressage, faut-il bien comprendre qu'il s'agit d'un transfert des donnés de la structure à l'adresse pData vers la variable PobjData en se référent au format de la structure STRUCTURE_1 ?

3/ J'ai des lignes de code avec ce même type de syntaxe où il y a 2 Astérix. Quelle est la différence ?

Merci beaucoup de votre aide.

1/ Les espaces avant ou après l'étoile n'ont aucune importance. La forme utilisée est de l'avis de chacun / de la convention d'écriture choisie. Personnellement, je n'aime pas la coller à la variable car cela fait partie du type est j'aime avoir un espace entre les 2.

2/ Je ne sais pas ce que tu entends par transfert, mais un cast d'un pointeur à un autre ne fait que dire au compilateur que le pointeur sur A est en fait un pointeur sur B. Les données pointées ne changent pas.
Au passage, ton cast est un cast à la C, qui n'est absolument pas sécurisé alors que le C++ propose static_cast et le risqué reinterpret_cast.

Salut,

Il n'y a aucune différence entre type *pointer(un espace entre type et l'astérisque, mais pas entre l'astérisque et l'identifiant de la donnée) et type* pointer(pas d'espace entre type et l'astérisque, mais bien entre l'astérisque et l'identifiant de la donnée). Ni même avec type * pointer (un espace entre type et l'astérisque, et un autre entre l'astérisque et l'identifiant de la donnée), ou type*pointer(aucun espace du tout.

Certains développeurs préféreront (pour des raisons qui leur sont propres) l'une ou l'autre de ces écritures, mais cela n'aura absolument aucune incidence réelle sur le code en lui-même (hormis la lisibilité).

Car le fait est que la grammaire à respecter consiste à fournir quatre éléments distincts (dont deux sont optionnels):

1. un "type identifier" (un identifiant de type)
2. un "cv qualifier" (un qualificatif de constance ou de volatilité): le mot clé const ou le mot clé volatile (optionnel)
3. un "memory access spécifier" (un spécificateur d'accès mémoire): savoir s'il s'agit d'une valeur (sans aucun signe particulier), d'un pointeur (l'astérisque) ou d'une référence (une esperluette) (optionnel)
4. un "data identifier" (un identifiant de donnée) dont le type correspond au deux premiers éléments.

Or, la règle pour retrouver les "identifiants" et les mots clé est relativement simple, dans le sens ou

• la première lettre est forcément une lettre (majuscule ou minuscule) ou un "underscore" _
• suivie (de manière optionnelle) par un nombre inconnu de lettres (minuscule ou majuscule), de chiffres ou d'underscore _

A partir de là, lorsque le compilateur rencontre, en début d'instruction, une lettre ou un underscore, il va considérer qu'il s'agit d'un identifiant (de type) qui s'arrête forcément au premier caractère qui ne soit ni une lettre, ni un chiffre, ni un underscore. Ce sera très souvent un espace, mais ce pourrait tout aussi bien être

• un symbole de tabulation ('\t')
• un retour à la ligne ('\n')
• une esperluette &
• une astérisque *
• en gros: tous les autres caractères auxquels te donne accès ta table de caractères ;)

Si bien que ton astérisque va ** forcément ** servir de séparateur entre les deux identifiants qui sont requis, vu que ce n'est ni une lettre, ni un chiffre, ni un underscore, et qu'elle suffit parfaitement à ce rôle. Si le développeur décide d'ajouter un (ou plusieurs) espace(s) avant ou après, il sera (ils seront) d'office ignoré(s), quelle qu'en soit la forme ;)

Il n'y aura vraiment que si un cv_qualifier apparait dans le code qu'il faudra -- forcément -- ajouter un espace entre l'identifiant de type et le mot clé en question (et entre le mot clé et l'identifiant de donnée) pour permettre au compilateur de se rendre compte qu'il s'agit de mots séparés ;)

Merci à jo_link_noir et à koala01 !

Je crois que c'est très complet, même si j'ai un peu de mal à retrouver les "petits" car je n'ai pas la même manière de penser pour tout ce qui est C++, Puisque je suis en Windev.

En tous cas c'est une avancée qui va me permettre de mieux comprendre les fonctions que je dois utiliser.

Veuillez m'excuser pour le "Asterix", au lieu de astérisque, automatiquement corrigé lors de mon écriture.

Merci encore

Citation:

---

Envoyé par didierma34

1/ Est-ce le même résultat dans les deux cas ?

---

C'est la même chose ... mais c'est assez subtil :mrgreen:
Les gens préfèrent coller l'astérique à la variable parce que l'astérique ne s'applique qu'à la variable.

Code:

---

1 2 3

int *pvar1; // pvar1 est 1 pointeur int* pvar2, var1; // pvar2 est 1 pointeur, var1 est 1 entier int var2, *pvar3; // pvar3 est 1 pointeur, var2 est 1 entier

---

Citation:

---

Envoyé par didierma34

2/ Sachant que le pData est le pointeur d'adressage, faut-il bien comprendre qu'il s'agit d'un transfert des donnés de la structure à l'adresse pData vers la variable PobjData en se référent au format de la structure STRUCTURE_1 ?

---

Dans 1 pointeur, tu stockes 1 adresse d'1 variable. Il n'y a pas de transfert ni dédoublement.
Tu as 1 variable de type STRUCTURE_1 et maintenant tu as 2 pointeurs qui pointent vers cette structure ... si pData est valide :whistle:
Le terme technique :mrgreen: : "shallow copy"

Citation:

---

Envoyé par didierma34

3/ J'ai des lignes de code avec ce même type de syntaxe où il y a 2 Astérix. Quelle est la différence ?

---

C'est l'étape d'après :mrgreen: 1 double pointeur c'est très très souvent l'adresse d'1 pointeur.
L'idée est de passer 1 pointeur mais qu'on veut affecter avec l'adresse d'1 nouvelle allocation. Donc ce n'est pas que des déréférencements, mais 1 [des] affectation(s)
L'alternative c'est de retourner cette adresse.