warning - string c++

¿Qué tiene más sentido: char*string o char*string?

Question

Posible duplicado:
En C, ¿por qué es el asterisco antes del nombre de la variable, en lugar de después del tipo?

Estoy aprendiendo C ++ en este momento, y estoy encontrando muchas cadenas terminadas en nulos. Esto me hizo pensar, lo que tiene más sentido a la hora de declarar punteros:

char* string

o

char *string

? Para mí, el formato char * tiene más sentido, porque el tipo de "cadena" es un puntero a un char, en lugar de un char. Sin embargo, generalmente veo el último formato. Esto también se aplica a las referencias, obviamente.

¿Podría alguien decirme si hay una razón lógica para este último formato?

Answer 1

(std :: string es mejor que char * para la mayoría de los usos).

Siempre coloco * con el tipo, como en char * porque, como señaló Stroustrup , esto enfatiza el tipo.

Y nunca declaro variables juntas en una línea para evitar el gotcha común discutido en las respuestas aquí;

char* p, q; // oops, probably not what was meant
// this is mandated by our style guide:
char* p;
char* q;

Answer 2

Bjarne Stroustrup tiene algo que decir al respecto :

La confusión crítica viene (solo) cuando las personas intentan declarar varios punteros con una sola declaración:

int* p, p1; // probable error: p1 is not an int*

Answer 3

En C ++ tiene sentido poner * en el identificador de tipo como char *, ya que es parte del tipo en sí.

Pero si define múltiples variables en la misma declaración, esto se vuelve ambiguo y engañoso.

char* foo, bar;

Mientras que foo tiene el tipo char * ahora, bar tiene el tipo char. Por lo tanto, muchas personas prefieren

char *foo, bar;

para dejar esto en claro.

Answer 4

En la mayoría de los casos, std::string str es mucho mejor que un char * .

Dicho esto, suelo hacer algo como DataType * ptr , para que * destaque mejor. O, con mucha más frecuencia, std::tr1::smart_ptr<DataType> ptr , o quizás un auto_ptr .

Muy simple, los punteros crudos son peligrosos de usar de varias maneras, y si voy a usar uno, quiero que se destaque.

Answer 5

En la siguiente declaración:

char* string1, string2;

string1 es un puntero de carácter, pero string2 es un solo carácter. Por esta razón, la declaración generalmente tiene el siguiente formato:

char *string1, string2;

lo que hace que sea ligeramente más claro que * aplica a string1 pero no a string2 . Una buena práctica es evitar declarar múltiples variables en una declaración, especialmente si algunas de ellas son punteros.

Answer 6

La primera sugerencia (de char * var) estaría bien siempre que solo declaraste una sola variable por línea, pero personalmente, prefiero la "char * var"; y una sola variable por línea: puede hacer que la función sea más larga en el recuento de líneas, pero es muy clara.

Finalmente, C ++ debe usar "var cadena", pero siempre terminamos heredando código con "char *" o teniendo que conectarnos a bibliotecas que no son de C ++.

Answer 7

Lo que nadie mencionó aún es que el siguiente

char *string

también se puede leer declarando el tipo de la expresión *string (léase: el operador indirecto aplicado a la string del puntero) como char . Desde este punto de vista, la notación es perfectamente razonable.

Dicho eso, yo uso

char * string

yo mismo;)

Answer 8

Mi respuesta: tampoco, deberías usar:

char * string;

Considere, si Dennis Ritchie (diseñador del lenguaje C) en lugar de usar el carácter ''*'' hubiera usado una palabra clave ''ptr'', todos tendríamos que decir:

char ptr string;

y no tener estas discusiones.

También es, en mi humilde opinión, más legible.

Answer 9

Personalmente, nunca declaro múltiples variables en una línea.

Debido a eso y al hecho de que realmente encuentro buenos patrones, encuentro que este patrón simple es atractivo:

type varname

Esto significa que casi siempre digo int [] iArray o int * piArray (o cualquiera que sea la notación húngara, no he usado C ++ en una década).

Esto también significa que nunca uso int iArray [], ya que el hecho de que sea una matriz es parte del tipo, no del nombre de la variable.

Pensar de esta manera también me ha ayudado a simplificar las definiciones algunas veces.

Solo ofreciendo otro punto de vista

Answer 10

Realmente me gusta el modismo " char* foo ", porque pone toda la información sobre el tipo de variable en un solo lugar. " char *foo " puede ser bastante confuso si la parte " *foo " está tabulada en la mitad de la pantalla.

Por otro lado, estoy de acuerdo con otros carteles que es confuso cuando se declaran múltiples variables en una línea. Intento no mezclar tipos cuando declaro múltiples variables en una línea, y char y char* son tipos separados en mi mente, por lo que esa situación particular no es la que probablemente ocurriría en mi código.

Answer 11

Técnicamente, tiene sentido escribir

char *f

Porque *f es el declarante en eso, mientras que el char es el especificador de declaración que especifica un tipo básico de todos los declaradores. Los declaradores contienen operadores como () , [] y & que pueden pensarse en modificar el tipo base y el identificador real.

Utilizo la forma anterior de poner * en el identificador porque enfatiza que *f realidad es el declarador, mientras que char es el tipo básico.

Hasta cierto punto, uno puede pensar en los modificadores en un declarador para hacer el tipo en el especificador de declaración cuando los operadores se aplican al identificador. Pero no siempre funciona:

int a, *b, &c = a, d(), e[1], C::*f;

Observe cómo todos los a , *b , d() y e[1] se resuelven estáticamente a un int, aparte de &c y C::* que declaran una referencia (por lo tanto, debe inicializarse) y un puntero a un miembro de la clase respectivamente.

Answer 12

Yo también creo que el char * foo tiene más sentido cuando se declara una sola variable.

La única vez que uso el otro formato es cuando declaro múltiples variables en una sola línea, como:

char * foo, bar;

Answer 13

dado que puede hacer múltiples declaraciones en una sola línea, tiene más sentido para mí que pertenezca a la variable en lugar del tipo, por ejemplo

char *pString, arrString[20];