2012-01-14 12 views
6

Sto cercando di capire le implicazioni /effetti collaterali/vantaggi di una recente modifica del codice qualcuno ha fatto. Il cambiamento è la seguente:Quale scopo serve questo codice?

originale

static List<type1> Data; 

Modificato

static List<type1> & getData (void) 
{ 
    static List<type1> * iList = new List<type1>; 
    return * iList; 
} 
#define Data getData() 

Quale scopo potrebbe servire il cambiamento?

+0

forse per evitare una sorta di inizializzazione statico problema? – Anycorn

+2

'#define dati ...' sta solo cercando problemi – tenfour

+0

@ Lol4t0: potresti spiegare un po 'di più riguardo il tuo commento? Come non è thread sicuro? – Lazer

risposta

4

Il vantaggio della revisione che riesco a vedere è un problema di "tempo di inizializzazione".

Il vecchio codice ha attivato un'inizializzazione prima che venga chiamato main().

Il nuovo codice non avvia l'inizializzazione finché getData() non viene chiamato per la prima volta; se la funzione non viene mai chiamata, non si paga mai per inizializzare una variabile che non si è utilizzata. Lo svantaggio (minore) è che c'è un controllo di inizializzazione nel codice generato ogni volta che viene utilizzata la funzione, e c'è una chiamata di funzione ogni volta che è necessario accedere all'elenco dei dati.

+0

E per quanto riguarda la durata del valore una volta inizializzata? Sarà lo stesso? – Lazer

+0

Una volta inizializzato, dura "per sempre" (finché il programma non termina). Dovrebbe essere distrutto in modo pulito, credo, se il programma esce sotto controllo. (Oh, ma è allocata dinamicamente, forse solo "perdite" quando il programma termina? Una tale "perdita" è piuttosto innocua a meno che il tipo di dati che è nella lista non acquisisca risorse che devono essere formalmente rilasciate quando il programma viene chiuso.) –

+0

@Lazer: Sì. la durata è la stessa come nel caso del codice originale. –

3

Se si dispone di una variabile con durata statica, viene creata quando l'applicazione viene inizializzata. Quando l'applicazione termina, l'oggetto viene distrutto. Non è possibile controllare l'ordine in cui vengono creati diversi oggetti.

La modifica creerà l'oggetto da creare quando viene utilizzato per la prima volta e (poiché viene assegnato dinamicamente) non verrà mai distrutto.

Questa può essere una buona cosa se altri oggetti hanno bisogno di questi oggetti quando vengono distrutti.

Aggiornamento

Il codice originale accedere l'oggetto utilizzando la variabile Data. Il nuovo codice non deve essere modificato in alcun modo. Quando il codice utilizza Data, infatti, utilizzerà la macro Data, che verrà espansa in getData(). Questa funzione restituirà un riferimento all'effettivo (oggetto assegnato dinamicamente). In pratica, il nuovo codice funzionerà come una sostituzione drop-in per il vecchio codice, con l'unica differenza evidente che è quella che ho descritto nella risposta originale sopra.

+0

Sì, l'oggetto non verrà distrutto, ma come sarà accessibile? – Lazer

+0

Sarà accessibile ogni volta che qualcuno chiama 'getData', Lazer. –

1

Ritardare la costruzione fino al primo utilizzo di Data evita "static initialization order fiasco".

Facendo alcune ipotesi circa la vostra List, ... il default-costruito Data è probabilmente una lista vuota di type1 elementi, in modo che probabilmente non è a grande rischio di causare il fiasco in questione. Ma forse qualcuno ha ritenuto che fosse meglio prevenire che curare.

Problemi correlati