Le variabili locali vengono cancellate dopo l'esecuzione della funzione?

[American]

Salve vorrei capire in linea generale (senza quindi parlare di un particolare linguaggio di programmazione), le variabili locali, ovvero dichiarate all'interno delle funzioni, vengono automaticamente cancellate all'uscita della funzione? Quindi parlando di spazio occupato in memoria, si può tranquillamente dire che una variabile globale resta in memoria (occupando quindi spazio) per tutta la durata del programma, a differenza di quelle locali che invece vengono auto-eliminate (garbage collected?).
Se si, in linea di massima un programma ottimizzato dovrebbe avere quanto meno variabili globali possibili?

Inoltre se le variabili locali vengono eliminate, perchè in alcuni casi (a meno che non vado errato) è possibile ugualmente accedervi dall'esterno? Vuol dire che restano in memoria...

[American]

Ho seguito un po' di testi riguardanti la programmazione ad oggetti (nello specifico incentrati su Java).
Posso comunque dire che, guardando sempre al lato dello spreco di risorse, c'è qualcosa che non mi torna nell'intera faccenda legata all'ereditarietà.
Tralasciando le varie classi create da un utente, che possono più o meno essere ottimizzate, vediamo come è strutturato lo stesso linguaggio java...

Ciascuna classe è sempre ereditata dalla classe Oggetto, cioè, se io creo una classe class casa, questa eredita tutti i metodi ed attributi specifici della classe Object
http://docs.oracle.com/javase/1.4.2/...ng/Object.html

Ma se io non prevedo di utilizzare molti dei metodi e degli attributi specifici della classe Object, il fatto di averli solo "istanziati" non rappresenta un inutile spreco di memoria?
Già durante l'esecuzione di un semplice programma dove magari viene "printato" a schermo una parola ed un numero int, entrano in gioco un'infinità di metodi e attributi specifici delle classi string, number e object, figuriamoci in gerarchie di classi molto più profonde

[MItaly]

Uhm, perché pensi che avere tanti metodi corrisponda ad uno spreco di memoria in ogni oggetto? Non è che il codice di ciascun metodo (e ciascuna property, che di fatto è una coppia di metodi sotto mentite spoglie) viene incorporato in ogni oggetto... Di base un oggetto necessita di contenere soltanto i campi (le "variabili membro" che contengono effettivamente dati) e eventualmente la vtable, tutto il resto è zucchero sintattico per chiamate a funzione.

Ora, in C++ se un oggetto non ha metodi virtuali non serve neanche la vtable - tutte le chiamate ai metodi sono risolte a compile-time, per cui non è necessario che l'oggetto si tiri dietro nulla di più dei suoi campi; se invece ci sono metodi virtuali (e in Java se non erro tutti i metodi sono virtuali) ed è necessario avere informazioni sul tipo a runtime (e Java ha potenti funzionalità di reflection) basta che ogni oggetto contenga giusto un puntatore in più ad una struttura dati che identifichi univocamente il tipo dell'oggetto (per la reflection) e contenga tutti i puntatori a funzione necessari per implementare le funzioni virtuali. Per questo motivo, ci sarà una singola istanza per tipo di ciascuna di queste strutture, a cui tutti gli oggetti di quel tipo puntano; ergo, il costo in termini di memoria per implementare funzioni virtuali e reflection è di un "metaoggetto" per ogni tipo definito e di un puntatore per ciascuna istanza del tipo; ergo, è tutta roba piuttosto economica.

(poi in Java c'è di mezzo anche la questione del bytecode e compagnia che rende il tutto un po' meno diretto rispetto all'implementazione C++, ma guardando il bytecode Java che implementa le chiamate a metodi, tutto fa pensare ad un approccio classico "a vtable")

Inoltre, tieni conto che in Java i tipi primitivi (int, long, double, ...) sono una cosa a parte rispetto alla gerarchia degli oggetti ("int" non è una classe, né eredita da Object), sia per ragioni di performance (allocare roba nell'heap ogni volta che si vuole un int sarebbe uno spreco ridicolo), sia per ragioni di semantica (nessuno si aspetta che gli int abbiano semantica per riferimento).