Sintassi per dereferencing un puntatore in C (o C++)

ho avuto un controllo collega in codice come questo in C (sintassi # 1):Sintassi per dereferencing un puntatore in C (o C++)

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

Quando gli ho chiesto perché non ha usato -> (sintassi # 2):

p_member->p_member->p_member->member

ha ottenuto veramente difensiva affermando che la sintassi # 2 è più complicato di 1 # ... ho finito per cambiare il suo codice perché ho dovuto modificarlo e non poteva leggerlo, poi si è arrabbiato perché l'ho effettivamente toccato ...

Quale sintassi preferisce la comunità SO? Entrambi sono validi, ma trovo la sintassi n. 2 più leggibile.

Lo sto impostando su wiki della comunità perché la domanda è soggettiva.

fonte

2009-04-28 paquetp

Stai confondendo la precedenza di * e. nel tuo primo frammento? –

In # 2, si dovrebbe accedere anche all'ultimo elemento, membro, usando -> – Trent

Francamente, non lo considero nemmeno soggettivo. Data la scelta di tre operatori (tra cui il()) e uno, puoi indovinare cosa sceglierei. – ojrac

Il termine tecnico per la sintassi n. 1 è "noci".

Detto questo, mi preoccuperei un po 'del codice che deve essere indiretto anche 3 volte.

fonte

2009-04-28 15:50:02

heheh ... indirection era dovuto a un modello di dominio rappresentato in C. – paquetp

Pensare a utilizzare un puntatore temporaneo se è necessario farlo più di uno: thingie_s * tp; ... tp = p_member-> p_member-> p_member; quindi passare indirettamente una volta attraverso tp. –

Oh sì, certo, certo ... specialmente se lo fai più di una volta. – paquetp

Prendo la porta numero 2, Monty! Certo, è più difficile da digitare, ma è più chiaro che scoprire quali operatori dereferenziano quale puntatore.

fonte

2009-04-28 15:47:41

FYI - Monty = Monty Hall of "Facciamo un affare" fama –

Spero che questo sia uno scherzo. –

In C++ utilizzerei sicuramente ->, perché -> può essere sovraccaricato.

In C vorrei usare -> anche perché è molto più facile da leggere, più veloce da digitare e meno incline agli errori (spero che il tuo collega non si perda tra parentesi!).

fonte

2009-04-28 15:49:03

Penso che il sovraccarico sia una falsa pista qui. Un iteratore funzionerà con p-> a o (* p) .a. Usa -> perché è molto più facile da leggere e molto meno soggetto a errori. Ricorda che * (p.a) e (* p) .a sono due cose diverse, quindi devi ricordarti di usare (* p) .a, ma p-> a è bello e semplice. –

In teoria l'operatore *() e l'operatore ->() potrebbero essere sovraccaricati per fare cose molto diverse ... speriamo di no, però. – ephemient

-> è spesso sovraccarico per i puntatori intelligenti –

soggettivo eh?

Prenderò anche il n. 2!

fonte

2009-04-28 15:49:13 toto

La seconda variante appare ovviamente più chiara. L'unico motivo per preferire # 1 è il caso di qualche operatore strano * e operatore -> sovraccarico quando # 1 ha un effetto molto diverso da # 2.

fonte

2009-04-28 15:50:11 sharptooth

e se gli operatori sono stati sovraccaricati in modo tale da avere effetti "davvero diversi", l'autore di quel codice deve essere trascinato indietro e girato. – rmeador

sovraccarico di questi operatori sarà vietato negli standard di codifica di qualsiasi progetto in cui lavoro. –

-1

No 2.

Detto questo, non offendere le persone cambiando il loro codice, soprattutto se si tratta di una questione di stile. Non ne vale la pena.

fonte

2009-04-28 15:56:04

Se devo capire cosa dice una singola riga di codice, piuttosto che leggerla e continuare a muoversi, questo è un problema di qualità. Lo cambierei in un istante. –

Quindi, come è possibile lavorare con altre persone che hanno opinioni diverse su cosa è leggibile e quali no? Lavoro con altri 40 (e intelligenti!) Sviluppatori e praticamente tutti hanno la loro idea di come il codice debba essere formattato e ciò che è leggibile. Se ci calpestassimo a vicenda in quel modo, lavorare insieme sarebbe un inferno e non avremmo mai realizzato nulla. –

Penso che gli standard di codifica dovrebbero essere concordati. Avere una base di codice con un milione di stili di codifica diversi è un incubo tutto suo. – jdizzle

Si potrebbe anche voler discutere la nozione di "proprietà del codice" nel proprio team. Il tuo collega non "possiede" il codice, l'azienda lo fa. Quindi chiunque sia impiegato dall'azienda, a ragione, può modificarlo.

fonte

2009-04-28 16:01:07

La domanda qui non è chi possiede legalmente il codice, ma chi deve mantenere e eseguire il debug di una parte specifica della base di codici. Se è il collega, dico che il codice dovrebbe apparire come piace a lui, anche se la maggior parte di noi preferisce l'altro modo. –

Se qualcuno che legge questo vuole il resto della storia - ha iniziato il codice, ho dovuto "integrarlo" (aggiungerlo al controllo del codice sorgente, inserirlo nel processo corretto, fare in modo che quel processo chiami la sua funzione) ... non ha funzionato Lavorare, quindi ho dovuto finirlo. – paquetp

Nel mio libro, se non ha funzionato, non si lamenta del fatto che tu lo abbia cambiato. Certo, visto che preferisce il (* p). costruire su ->, non sono scioccato dal fatto che non ha funzionato. –

Penso che il tuo collega sia o inesperto, una sorta di neofobo, o semplicemente ol 'insensato. Scoprirai che la scelta unanime è usare la sintassi ->.

fonte

2009-04-28 16:01:30

Questo è quello che mi aspetto ... – paquetp

sto scrivendo a braccio qui, ma il mio ricordo è che la logica per l'esistenza stessa della -> operatore in C è stato spiegato nel 1 ° edizione del K & R come (parafrasando): perché altrimenti saremmo digitare (*p).a a causa della necessaria precedenza degli operatori * e ..

Per non utilizzare -> per lo scopo previsto è dadi.

fonte

2009-04-28 18:17:45 RBerteig

Cattivo collega. Cambia collega

fonte

2009-04-29 09:03:03

Ho avuto esperienze in cui "->" non è stato implementato correttamente in un paio di compilatori ...quindi il normale (* p) .a ha più probabilità di funzionare quando si hanno più livelli di nidificazione.

fonte

2009-07-21 02:24:09

Sintassi per dereferencing un puntatore in C (o C++)

risposta

Problemi correlati