2012-09-13 18 views
6

Nell'esempio di codice seguente alloco alcune istanze della struct Chunk. Nei cicli for, quindi, eseguo l'iterazione nel blocco di memoria e accedo alle diverse istanze utilizzando il puntatore oi riferimenti e assegna loro alcuni dati casuali.Qual è più veloce, accesso puntatore o accesso di riferimento?

Ma quale ciclo eseguirà il più veloce? A mia conoscenza, direi che il ciclo di riferimento sarà il più veloce perché non richiede il dereferenziamento e ha accesso diretto all'istanza in memoria. Quanto errato/giusto sono?

struct Chunk { 
    unsigned int a; 
    float b; 
    const char* c; 
}; 

int main() { 
    Chunk* pData = new Chunk[8]; 

    for(unsigned int i = 0; i < 8; ++i) { 
     Chunk* p = &pData[i]; 
     p->a = 1; 
     p->b = 1.0f; 
     p->c = "POINTERS"; 
    } 

    for(unsigned int i = 0; i < 8; ++i) { 
     Chunk& r = pData[i]; 
     r.a = 1; 
     r.b = 1.0f; 
     r.c = "REFERENCES"; 
    } 

    delete [] pData; 
    return 0; 
} 
+7

Dipende dal compilatore, suppongo, ma con il mio compilano lo stesso codice esatto. La maggior parte degli sviluppatori C++ preferisce i riferimenti come una questione di stile. –

+0

Ricorda che un riferimento è come un puntatore automaticamente de-referenziato. – tadman

+0

@tadman Non conforme allo standard. –

risposta

10

Dovrebbero essere gli stessi (non circa la stessa, ma esattamente lo stesso) con qualsiasi compilatore non idiota. Sotto il cofano, i riferimenti sono puntatori (sul 99% dei compilatori). Non c'è motivo di alcuna differenza.

Pedantic: il secondo ciclo potrebbe essere essere più veloce (probabilmente no) perché i dati sono già nella cache, ma il gioco è fatto. :)

+0

Spiegazione per il downvote? –

+0

Probabilmente un fanatico della C che ama le frecce meglio delle e commerciali. – tadman

+2

Non corretto al 100%. I riferimenti non sono puntatori, non sono affatto oggetti. Potrebbero essere implementati da indicatori in diversi casi, ma non al 100%. E il codice generato per il puntatore e per riferimento potrebbe essere diverso. – Rost

1

Non ci dovrebbero essere differenze nel codice prodotto da qualsiasi compilatore decente.

1

Quando esiti tra due versioni del codice come quelle del tuo esempio, dovresti scegliere quella più leggibile. Possibile ottimizzazione del tipo che si propone dovrebbe essere fatta dal compilatore.

Il più leggibile nel tuo caso è piuttosto la versione con riferimenti (in realtà, forse non molto più leggibile, ma il consenso è preferire l'uso dei riferimenti perché i puntatori sono più "pericolosi").

Ma torniamo all'effeciency: (per favore se qualcuno conosce l'assemblatore, meglio smettere di leggere o rischi di ridere un attacco ...) A mio parere, dato che il pData è posizionato nell'heap, il compilatore dovrà compilarlo usando comunque i puntatori. Penso che il tuo ragionamento potrebbe essere corretto se la tua struttura è stata allocata nello stack solo con "Chunk data [8];". Ma al più tardi quando le ottimizzazioni del compilatore sono sulla differenza dovrebbe essere cancellato comunque.

1

Sono tentato di dire: a chi importa? Qualsiasi differenza di velocità sarà trascurabile e dovresti scegliere il più leggibile. In questo particolare caso , mi aspetto di vedere esattamente lo stesso codice generato nel caso . Nei casi più complicati, il compilatore potrebbe non essere in grado di determinare in un secondo momento nel ciclo che il puntatore non è stato riposizionato, e potrebbe doverlo rileggere. Ma perché così sia, dovresti essere facendo abbastanza altre cose che la differenza non sarebbe misurabile.

+0

Grazie per la risposta. Questo è, come potresti notare, non un esempio reale. Mi sto solo chiedendo cosa dovrei scegliere in uno scenario più complesso. –

+0

@MichaelMancilla Qualunque cosa esprima meglio ciò che vuoi fare. Generalmente, riferimento quando possibile, e puntatore altrimenti. L'uso del riferimento dice al lettore (e al compilatore) che l'oggetto riferito non cambierà. –

+0

"Qualsiasi differenza di velocità sarà trascurabile," Il tuo caso d'uso non è altrui. – easytiger

Problemi correlati