100 votes

Manière correcte de déclarer des variables de pointeur en C / C ++

J'ai remarqué que certaines personnes d'utiliser la notation suivante pour déclarer des variables de pointeur.

(a) char* p;

au lieu de

(b) char *p;

J'utilise (b). Quelle est la justification de la notation (un)? La Notation (b) plus de sens pour moi, car pointeur de caractère n'est pas un type lui-même. Au lieu de cela, le type c'est le caractère et la variable peut être un pointeur sur le caractère.

char* c;

Cela ressemble à il ya un type char* et la variable c est de ce type. Mais en fait, le type est de type char, et *c (à l'emplacement mémoire pointé par le c) est de ce type (char). Si vous déclarer plusieurs variables à la fois, cette distinction devient évident.

char* c, *d;

Cela fait un peu bizarre. C et d sont sur un même type de pointeurs qui pointent vers un personnage. Dans ce puisque l'on y regarde de plus naturel.

char *c, *d;

Merci.

112voto

BlackJack Points 1479

Bjarne Stroustrup a dit:

Le choix entre "int* p;" et "int *p;" n'est pas sur le bien et le mal, mais sur le style et l'accent. C souligné expressions; les déclarations ont souvent été considérés comme un peu plus qu'un mal nécessaire. C++, d'autre part, a un lourd accent sur les types.

Typique d'un programmeur C", écrit "int *p;" et explique "*p est quel est l'int" mettre l'accent sur la syntaxe, et peut pointer vers le C (et C++) déclaration de grammaire pour plaider en faveur de la justesse du style. En effet, l' * lie pour le nom de p dans la grammaire.

Typique d'un programmeur C++", écrit "int* p;" et explique qu'il "p est un pointeur vers un int", soulignant type. En effet, le type de p est de type int*. De toute évidence, je préfère que l'accent et le voir comme importante pour l'utilisation les plus avancées de C++ bien.

Source: http://www.stroustrup.com/bs_faq2.html#whitespace

Je vous recommande le dernier style, parce que dans la situation où vous déclarer plusieurs pointeurs sur une seule ligne (votre 4ème exemple), avoir l'astérisque avec la variable sera ce que vous en avez l'habitude.

64voto

ikegami Points 133140

Personnellement, je préfère placer le * avec le reste du type

 char* p;  // p is a pointer to a char.
 

Les gens vont discuter "mais alors char* p, q; devient trompeur", ce à quoi je dis, "alors ne le faites pas".

37voto

George Gaál Points 623

Il n'y a pas de différence pour écrire. Mais si vous voulez déclarer deux pointeurs ou plus dans une ligne, il est préférable d’utiliser la variante (b), car il est clair ce que vous voulez. Regardez ci-dessous:

 int *a;
int* b;      // All is OK. `a` is pointer to int ant `b` is pointer to int
char *c, *d; // We declare two pointers to char. And we clearly see it.
char* e, f;  // We declare pointer `e` and variable `f` of char type.
             // Maybe here it is mistake, maybe not. 
// Better way of course is use typedef:
typedef char* PCHAR;
PCHAR g, h;  // Now `g` and `h` both are pointers.
// If we used define construction for PCHAR we'd get into problem too.
 

12voto

jnnnnn Points 1199

Le compromis est

 char * p;
 

K & R utilise

 char *p;
 

C’est à vous de décider, sauf si vous suivez une norme de codage - dans ce cas, vous devriez suivre ce que tout le monde fait.

2voto

Jesus Ramos Points 15798

Tout est une question de préférence, personnellement, sur des projets que je vois le char* j'ai tendance à déclarer plusieurs pointeurs sur des lignes séparées. Il n'existe pas de "bonne" façon de faire et tout se résume à la préférence. Certains disent que c'est plus facile à lire (a) tandis que d'autres disent que (b) est plus facile de déclarer plusieurs variables du même type sur la même ligne.

Je trouve (b) à être plus fréquente, et dans certains cas, j'ai vu

char * a;

ou quelque chose comme ça. Encore de préférence. Tout ce que vous êtes à l'aise avec ou quel que soit le projet, je travaille sur les utilisations que je vais utiliser (à moins que j'écris moi-même dans ce cas, je utiliser (a))

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X