If the object is only to be used within the scope of a few lines would
it be a waste of memory?
È difficile rispondere con precisione, ma io vado con "no" (non sono il tipo di persona su cui contare per precisione tecnica). Penso che sia meglio considerarlo semplicemente "no". Potrebbe esserci qualche caso davvero oscuro in cui ciò non è vero, ma lo vedo come meglio scoperto in una sessione di profiling quando analizzo lo smontaggio risultante, e anche allora direi ancora che la risposta è "no" e solo passare come una stranezza. :-D
Perché abbiamo già una quantità fissa di memoria veramente veloce messa da parte nei registri. I compilatori generalmente allocano queste variabili locali in registri. E la variabile non richiede necessariamente "memoria di registro in più" perché il risultato dell'espressione memorizzata dovrebbe essere generalmente spostato in un registro prima di poter eseguire qualsiasi istruzione su di esso.
E a volte i risultati vengono riversati nello stack, ma lo stack è la memoria preallocato che viene spuntata quando la variabile analogica esce dallo scope (o quando l'espressione non è più usata), e lo stesso si applica ai risultati dell'espressione che la variabile memorizza. Quindi, rispetto all'espressione stessa, il modo pratico di pensarlo dal punto di vista della memoria è che è assolutamente gratuito.
Aside from making it easier to type, readable, or maybe even
maintainable; what other merits are there?
Se il compilatore non è così intelligente, catturare i risultati di un'espressione in una variabile può aiutare a allocare i registri in modo più efficace ed evitare di ripetere le stesse istruzioni coinvolte per valutare l'espressione. Tuttavia, questo è un motivo generalmente orribile per usare più variabili per un'espressione di base, perché in primo luogo i compilatori sono in genere molto intelligenti, e in secondo luogo non è molto produttivo cercare di aiutare i compilatori ad eseguire l'allocazione dei registri e la selezione delle istruzioni. Vuoi andare con il flusso dell'ottimizzatore e lasciarti aiutare, non provare a sconfiggerlo e ad arrampicarti sulle dita dei piedi, altrimenti potresti anche scrivere codice in assembly.
Quindi penso che tu abbia già elencato la maggior parte dei meriti. Volevo entrare qui perché non è così raro incontrare persone che hanno paura di immagazzinare una variabile locale per paura di avere qualche tipo di impatto memoria / prestazioni, e che la paura potrebbe diventare molto controproducente. Quasi certamente non, e in qualche oscuro caso ipotetico, potrebbe effettivamente avere l'effetto opposto - ma ancora una volta non dovresti usare le variabili locali con l'intenzione di cercare di aiutare gli ottimizzatori in contrasto con le buone ragioni che hai elencato come leggibilità e manutenibilità. Lo sottolineo solo perché l'intuizione che le variabili locali costano qualcosa è potenzialmente sbagliata perché le stesse cose che si desidera memorizzare analogicamente alla variabile locale devono essere comunque spostate / caricate in un registro e sono suscettibili alle stesse fuoriuscite di stack. / p>
Personalmente mi piace quando le persone acquisiscono i risultati di un'espressione lunga su una variabile locale (o idealmente una costante denominata se non può cambiare da quel punto in poi), poiché non solo riduce la quantità di codice che devo leggere, ma anche comunicando che tutto ciò che fa riferimento da quel momento in poi accedendo alla stessa cosa a colpo d'occhio. E naturalmente legando all'esempio mantenibile, se l'ipotesi che tutto da quel punto in poi acceda allo stesso risultato, ti dà una riga di codice da cambiare se il risultato deve cambiare rispetto a molti.