Newsgroup: it.comp.lang.c++
Titolo: const e allocazione di memoria

Recentemente su una ML ho avuto una discussione circa l'uso di memoria
da parte di valori costanti.
Se io ho questo programma:
const int a=100;
int main() {
  int b=a;
};
è lecito aspettarsi che il compilatore non allocochi memoria per a ma
sostituisca direttamente il valore nell'inizializzazione di b (un po'
come se fosse una #define intelligente)?
Sino a due giorni fa non avrei avuto dubbi, e anche lo Stroustrup
diceva che era molto probabile, ma su questa ML uno mi ha fatto vedere
il disassemblato di un prog simile compilato con gcc sotto Linux, nel
quale si notava che in realtà la memoria per a veniva allocata!
Cosa ne dite?
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

 Cosa ne dite?
L'allocazione o meno della memoria dipende dal compilatore. E non solo per a!
Nel programma che hai scritto tu il compilatore potrebbe persino (anche se ne
dubito) compilarlo in un file che esegue solo la chiamata al SO (con valore 0)
senza neppure inizializzare le librerie e senza creare la funzione main! Tutto
cio' che e' garantito sono i side effects, e il tuo programma non ne ha.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

In teoria si ... il compilatore dovrebbe non allocare memoria!! Ma non
sempre, dipende dal compilatore. Per niente si usa la keyword volatile
quando si intende passare il controllo ad un altro processo che potrebbe
modificare il valore di quella costante! Non dichiarandola volatile, il
compilatore con opportune ottimizzazioni, non alloca memoria ma tratta la
const come fosse una #define

 come se fosse una #define intelligente)?
Per la cosiddetta "as if" rule, il compilatore e' libero di compiere
qualsiasi ottimizzazione che non alteri il comportamento visibile del
programma. Nel caso del tuo esempio potrebbe benissimo emettere un
eseguibile vuoto!
Si tratta di capire quali ottimizzazioni vengono effettivamente compiute
dallo specifico compilatore. Ad esempio il Borland elimina la costante
anche con tutte le ottimizzazioni disabilitate.
Ciao,
Nicola

Cosa ne dite?
Credo di avere letto da qualche parte che se non si attivano esplicitamente
le ottimizzazioni, gcc produce codice che fa esattamente quello che viene
detto, quindi, in questo caso, allocando memoria, eseguendo l'assegnamente
regolarmente, etc.
Dovresti provare a compilare con -Oqualcosa.
Lanugo

anche con tutte le ottimizzazioni disabilitate.
infatti; sapevo che il compilatore a norma di standard poteva fare
quello che voleva, ma volevo sapere se un programmatore può
ragionevolmente aspettarsi che lo faccia. E il gcc sembra che non lo
faccia :-( (non è che c'è qualche differenza tra C e C++ sotto questo
punto di vista?)


 punto di vista?)
Quali ottimizzazioni sono effettivamente implementate e' "implementation
defined", non per niente in comp.lang.c++.moderated si trovano
frequentemente risposte tipo: "un compilatore moderno", "un compilatore
appena decente", ecc.
Non conosco lo standard del C.
Ciao,
Nicola

 ha scritto nel messaggio
news:3AD6F2C0...@divalsim.it...


Per un compilatore che si fregia dell'appellativo "standard", e' proprio
lo standard e *solo* quello a determinare cosa puo' e non puo' fare.
Lo standard specifica esplicitamente che il compilatore puo' fare quello
che vuole, posto che il comportamento visibile del programma generato
sia "come se" lo standard stesso fosse stato seguito alla lettera.
Per comportamento visibile lo standard specifica che si tratta
dell'interazione con l'ambiente circostante (I/O) e dell'accesso alle
variabili dichiarate volatile.
Ciao,
Nicola

 ha scritto nel messaggio
news:3ADC1F0D...@divalsim.it...


Intendo dire che fa parte dei compiti dello standard delineare quali
ottimizzazioni sono ammesse o meno. Cio' non toglie che lo standard
lascia la massima liberta', a patto ovviamente che il risultato non
cambi.
Ciao,
Nicola

 ha scritto nel messaggio
news:3ADC57D7...@divalsim.it...


A livello di risultato no, a livello di forma si. Ad esempio una
conseguenza indiretta di come e' formulato lo standard e' che tutte le
ottimizzazioni che si basano su assunzioni implicite (ad esempio "tutte
le funzioni sono prive di aliasing") cadono al di fuori dello standard
stesso.
Ciao,
Nicola

riferimento a "v" con "5" senza particolari problemi. 
La variabile v potrebbe essere modificata da una funzione in un'altra
unità di compilazione; questo il compilatore non lo può sapere; in
teoria potrebbe farlo il linker, ma direi che sarebbe un po'
complicato


 complicato
Certo ... ma è il risultato che conta ... quel che vien fuori da tutta la
compilazione ... non solo dalla compilazione delle singole unità!! Infatti
alcuni compilatori tipo il DJGPP, lascia le informazioni di debug che
possono essere eliminate totalmente a risultato finito! Ma Cmq, questa fa
parte delle ottimizzazioni che molte volte vengono applicate sul risultato
della compilazione, dando un codice compilato perfettamente identico a
quello non ottimizzato per *operazioni*.