2011-12-19 12 views
6

Ho la funzione di registrazione chiamata in più punti del codice. Per ogni registro, devo fornire 2 costanti di tempo di compilazione. Ci sono 2 approcci per realizzare:Quale approccio è migliore per fornire costanti di tempo di compilazione a una funzione? Argomento funzione vs. Parametro modello

(1) di argomento di funzione:

template<typename T> 
void log (const T &obj, const int LINE, const int COUNT) 
{ 
    // T is used for some purpose 
    if(debug) 
    logging(obj.out(), LINE, COUNT); 
} 

chiamata come,

log(str, __LINE__, __COUNTER__); 

(2) parametro Template:

template<typename T, int LINE, int COUNT> 
void log (T &obj) 
{ 
    // T is used for some purpose 
    if(debug) 
    logging(obj.out(), LINE, COUNT); 
} 

chiamalo come,

log<__LINE__, __COUNTER__>(str); 

io non sono in grado di decidere, perché prima approccio offre la semplicità, ma stiamo passando costante in fase di compilazione. Il secondo approccio è perfetto, ma probabilmente il tempo di compilazione aumenterebbe. Questo compito è noioso e non ho ancora implementato nessuno di questi, quindi non ho alcun benchmark.

Sarà di grande aiuto se qualcuno può rispondere a questa esperienza/conoscenza.

+1

Come si definisce "migliore"? Entrambi funzionano *, quindi quali criteri useresti per dire che uno è migliore dell'altro? –

+0

@NicolBolas, perché voglio scegliere il migliore tra 2 in base al tempo di compilazione e al runtime. Inoltre c'è una leggera modifica nel codice di esempio. – iammilind

+0

Qualunque cosa faccia la funzione 'logging', sarà * certamente * più lenta che passare due interi come argomenti. Quindi non vedo come le prestazioni di runtime cambieranno molto in entrambi i modi. Questo suona sospettosamente come un'ottica prematura. –

risposta

3

Vorrei andare con la prima opzione. L'impatto sulle prestazioni del passaggio di due numeri interi è trascurabile. Probabilmente l'ottimizzatore incorpora la chiamata di funzione, nel qual caso non ci sarebbe differenza tra i due. La seconda opzione credo sia una cattiva idea, dato che creerai molte versioni della stessa funzione, senza motivo.

+0

Ok, c'è una leggera modifica nella sintassi della domanda. Il 'log' stesso è una funzione' template', ho pensato di non menzionarlo ...ma ho trovato che sarebbe stato utile. Inoltre, il compilatore non ottimizzerà anche le diverse versioni di 'template log'? – iammilind

+0

Beh, ci saranno solo poche versioni della prima funzione di registro, std :: string, std :: wstring, char *, wchar_t *. Mentre fondamentalmente ogni chiamata di funzione alla seconda versione risulterà in una nuova funzione. Probabilmente l'ottimizzatore lo gestirà, ma otterrai lo stesso risultato con tempi di compilazione più lunghi. – ronag

4

Poiché la scelta tra questi due fa la differenza rispetto al codice chiamante, suggerirei di accedere tramite una macro. Quindi non devi preoccuparti ora di quale di questi è meglio, perché è facile passare da uno all'altro.

Una volta che hai la tua vera domanda scritta, si può pasticciare con la definizione di macro per confrontare i due. Oppure no, se ci sono più aree produttive da ottimizzare. Se si riesce a fare una grande differenza, puoi anche lasciarlo aperto alla configurazione di build per decidere se usare -DLOGGING_COMPILES_QUICKLY o -DLOGGING_RUNS_QUICKLY.

Un altro potenziale vantaggio di una macro: è possibile disporre che il primo argomento venga valutato se e solo se debug è true. Non so che cosa l'interfaccia di str è, o dove gli oggetti vengono, ma se costa nulla per produrre il giusto valore da passare al log, e poi log non la usa nel caso non-debug, quindi questo è un potenziale spreco di runtime.

+0

Bella risposta ... La maggior parte delle volte LINE e COUNT non saranno utilizzati. Quale alternativa è meglio in questo caso il codice di produzione degli abeti? – iammilind

+0

@iammilind: Se 'debug' è una costante in fase di compilazione, e la chiamata a' log' è in linea, il codice emesso probabilmente dovrebbe essere lo stesso in entrambi i casi, sebbene si tratti di un problema di QOI. Se vuoi conoscere i dettagli per una particolare implementazione, controlla lo smontaggio. –

Problemi correlati