La mia domanda è basata sulla curiosità e non sul fatto che ci sia un altro approccio al problema o meno. È una domanda strana/interessante, quindi ti preghiamo di leggerla con una mente aperta.Iterare senza incorrere nel costo delle dichiarazioni IF
Supponiamo che ci sia un ciclo di gioco chiamato ogni frame. Il ciclo di gioco a sua volta chiama diverse funzioni attraverso una miriade di istruzioni if
. Ad esempio, se l'utente ha una GUI su false, non aggiornare la GUI, altrimenti chiama RefreshGui()
. Ci sono molte altre istruzioni if
nel ciclo e chiamano le loro rispettive funzioni se sono vere. Alcuni sono if/if-else.../else
che sono più costosi nel peggiore dei casi. Anche le funzioni chiamate, se l'istruzione if
è vera, hanno una logica. Se l'utente desidera il raypicking su tutti gli oggetti chiama FunctionA()
, se l'utente desidera raypicking sulle luci, chiama FunctionB(), ..., altrimenti chiama tutte le funzioni. Spero che tu abbia l'idea.
Il mio punto è che si tratta di molte affermazioni ridondanti. Così ho deciso di usare invece i puntatori di funzione. Ora la mia ipotesi è che un puntatore a funzione sarà sempre più veloce di una dichiarazione if
. È un sostituto per se/else. Quindi, se l'utente desidera passare tra due diverse modalità di fotocamera, lui/lei preme la chiave C
per alternare tra loro. La funzione di callback per la tastiera cambia il puntatore alla funzione UpdateCamera
corretta (in questo caso, il puntatore della funzione può puntare a UpdateCameraFps()
o UpdateCameraArcBall()
) ... ne viene il senso.
Ora alla domanda stessa. Cosa succede se ho diverse funzioni di aggiornamento tutte con la stessa firma (diciamo annullamento (*Update)(float time)
), in modo che un puntatore a funzione possa potenzialmente puntare a una di esse. Quindi, ho un vettore che viene utilizzato per memorizzare i puntatori. Poi nel mio ciclo di aggiornamento principale, vado attraverso il vettore e chiamo ogni funzione di aggiornamento. Posso rimuovere/aggiungere e persino modificare l'ordine degli aggiornamenti, senza modificare il codice sottostante. Nel migliore dei casi, potrei chiamare solo una funzione di aggiornamento o, nel peggiore dei casi, tutte, tutte con un ciclo while molto pulito e nessuna istruzione negativa (potenzialmente annidata). Ho implementato questa parte e funziona benissimo. Sono consapevole del fatto che, ad ogni iterazione del ciclo while responsabile per l'iterazione attraverso il vettore, sto verificando se lo itrBegin == itrEnd
. Più precisamente while (itrBegin != itrEnd)
. C'è un modo per evitare la chiamata alle istruzioni if? Posso usare la previsione del ramo a mio vantaggio (o ne approfitto già senza saperlo)?
Ancora una volta, si prega di prendere la domanda così com'è, io non sto cercando un approccio diverso (anche se sei più che benvenuto a dare uno).
EDIT: Alcuni risposte affermano che si tratta di un'ottimizzazione prematura non necessario e non dovrebbe concentrarsi su di esso e che il costo se-statement (s) è minuscola rispetto al lavoro svolto in tutte le funzioni di aggiornamento separati . Verissimo, e sono completamente d'accordo, ma non era questo il punto della domanda e mi scuso se non ho chiarito la questione. Ho imparato un bel po 'di cose nuove con tutte le risposte però!
Se ognuna di queste funzioni sta eseguendo un'attività "grande" (come l'aggiornamento della GUI), sicuramente il costo di un singolo confronto è assolutamente irrilevante al confronto? Hai effettivamente profilato per vedere quale percentuale del tempo speso nel tuo ciclo di driver? Scommetto che questa "ottimizzazione" non vale il costo dell'offuscamento del codice. –
* [...] quindi per favore leggilo con una mente aperta "* Questo tipo di affermazione mi rende * tanto * molto più probabile leggere ciò che segue con attenzione a come potrebbe essere legittimamente chiuso. Ma ... um .. .se stai utilizzando un linguaggio polimorfo, ad esempio C++, perché non usi questa caratteristica del linguaggio per risolvere questo problema? È un classico caso d'uso per mostrare come il codice OOP può essere più pulito di quanto non lo sia codice. :: sheesh :: – dmckee
+1 Interessante domanda con buone intenzioni. –