Sintaxis para dereferencing un puntero en C (o C++)

tuve un cheque colega en código como este en C (sintaxis # 1):Sintaxis para dereferencing un puntero en C (o C++)

(*(*(*p_member).p_member).p_member).member

Cuando le pregunté por qué no usar -> (sintaxis # 2):

p_member->p_member->p_member->member

se puso muy defensiva que indica que la sintaxis # 2 es más complicado que el # 1 ... acabé cambiando su código porque tuve que modificarlo y no podía leerlo, luego se enojó porque realmente lo toqué ...

Qué sintaxis ¿La comunidad SO lo prefiere? Ambos son válidos, pero encuentro que la sintaxis # 2 es más legible.

Estoy estableciendo esto en la wiki de la comunidad debido a que la pregunta es subjetiva.

Fuente

2009-04-28 paquetp

¿Está confundiendo la precedencia de * y. en tu primer fragmento? –

En el n. ° 2, también se debe acceder al último elemento, miembro, utilizando -> – Trent

Francamente, ni siquiera lo considero subjetivo. Dada la elección de tres operadores (incluido el()) y uno, puedes adivinar qué elegiría. – ojrac

El término técnico para la sintaxis # 1 es "nuts".

Dicho esto, me preocuparía un poco sobre el código que tiene que ser indirecto 3 veces también.

Fuente

2009-04-28 15:50:02

heheh ... indirección se debió a un modelo de dominio representado en C. – paquetp

Piense en utilizar un puntero temporal si necesita hacer esto más de uno: thingie_s * tp; ... tp = p_member-> p_member-> p_member; luego vaya indirectamente una vez a tp. –

Oh sí, claro, por supuesto ... especialmente si lo haces más de una vez. – paquetp

Voy a tomar la puerta # 2, Monty! Claro que es más difícil de escribir, pero es más claro que descubrir qué operadores desreferencian qué puntero.

Fuente

2009-04-28 15:47:41

FYI - Monty = Monty Hall de la fama de "Hagamos un trato" –

Espero que esto sea una broma. –

En C++ Definitivamente usaría ->, porque -> puede estar sobrecargado.

En C Yo usaría -> también porque es mucho más fácil de leer, más rápido de escribir y menos propenso a errores (¡espero que su colega no se pierda entre paréntesis!).

Fuente

2009-04-28 15:49:03

Creo que la sobrecarga es una gran amenaza aquí. Un iterador funcionará con p-> a o (* p) .a. Use -> porque es mucho más fácil de leer y mucho menos propenso a errores. Recuerde que * (p.a) y (* p) .a son dos cosas diferentes, por lo que debe recordar usar (* p) .a, pero p-> a es agradable y simple. –

En teoría, el operador *() y el operador ->() podrían estar sobrecargados para hacer cosas muy diferentes ... aunque afortunadamente no. – ephemient

-> a menudo está sobrecargado para los punteros inteligentes –

subjetiva ¿eh?

¡Voy a tomar el # 2 también!

Fuente

2009-04-28 15:49:13 toto

La segunda variante obviamente parece más clara. La única razón para preferir el # 1 es el caso de algún extraño * operador y operador -> sobrecarga cuando el # 1 tiene un efecto realmente diferente al # 2.

Fuente

2009-04-28 15:50:11 sharptooth

y si los operadores se han sobrecargado de modo que tengan efectos "realmente diferentes", el autor de ese código debe arrastrarse hacia atrás y dispararse. – rmeador

la sobrecarga de estos operadores estará prohibida en los estándares de codificación de cualquier proyecto en el que trabaje. –

-1

No 2.

Una vez dicho esto, no ofender a la gente cambiando su código, sobre todo si se trata de una cuestión de estilo. No vale la pena.

Fuente

2009-04-28 15:56:04

Si tengo que averiguar qué dice una sola línea de código, en lugar de leerla y seguir moviéndome, ese es un problema de calidad. Lo cambiaría en un abrir y cerrar de ojos. –

Entonces, ¿cómo puede trabajar con otras personas que tienen diferentes opiniones, qué es legible y qué no? Trabajo con otros 40 desarrolladores (¡e inteligentes!) Y prácticamente todo el mundo tiene su idea de cómo se debe formatear el código y qué es legible. Si pisáramos los unos a los otros de esa manera, trabajar juntos sería un infierno y nunca hubiéramos logrado nada. –

Creo que las normas de codificación tendrían que ser acordadas. Tener una base de código con un millón de estilos de codificación diferentes es una pesadilla propia. – jdizzle

Es posible que desee discutir la noción de "propiedad del código" en su equipo. Tu colega no "posee" el código, la empresa sí. Por lo tanto, cualquier persona empleada por la empresa, con buena razón, puede editarla.

Fuente

2009-04-28 16:01:07

La pregunta aquí no es quién posee legalmente el código, sino quién necesita mantener y depurar una parte particular de la base de código. Si es el compañero de trabajo, digo que el código debe verse como a él le gusta, incluso si la mayoría de nosotros prefiere la otra opción. –

Si alguien que lea esto quiere el resto de la historia, comenzó el código, tuve que "integrarlo" (agregarlo al control de código fuente, ponerlo en el proceso adecuado, hacer que ese proceso llame a su función) ... no lo hizo No funciona, así que tuve que terminarlo. – paquetp

En mi libro, si no funcionó, no puede quejarse de que lo cambie. Por supuesto, dado que él prefiere el (* p). construir sobre ->, no estoy sorprendido de que no funcionó. –

Creo que su compañero de trabajo no tiene experiencia, es una especie de neófito o simplemente no tiene ni idea. Descubrirá que la elección unánime es usar la sintaxis ->.

Fuente

2009-04-28 16:01:30

Eso es lo que espero ... – paquetp

Estoy escribiendo aquí, pero mi recuerdo es que la lógica para la existencia misma del operador -> en C se explicó en la 1ª edición de K & R como (paráfrasis): porque de lo contrario hubieras tiene que escribir (*p).a debido a la necesaria precedencia de los operadores * y ..

Para no utilizar -> para su fin previsto es tuercas.

Fuente

2009-04-28 18:17:45 RBerteig

Mal colega. Cambiar colega

Fuente

2009-04-29 09:03:03

He tenido experiencias donde "->" no se implementó correctamente en un par de compiladores ...por lo que lo normal (* p) .a era más probable que funcionara cuando tienes múltiples niveles de anidación.

Fuente

2009-07-21 02:24:09

Sintaxis para dereferencing un puntero en C (o C++)

Respuesta

Cuestiones relacionadas