Newsgroup: it.comp.lang.c++
Titolo: Dimensione dei file compilati con DGJPP

Forse è una domanda molto ingenua, ma...
Ho scritto un piccolo programmino di prova per cominciare a riprendere
la mano con la programmazione, ed esercitarmi un po' con il C++. E' un
file .cc lungo 3k. L'ho compilato con il DGJPP (l'unico compilatore C++
che ho attualmente) e ne è uscito un file di quasi mezzo MB!
D'accordo, ci sono gli #include di 4 file; d'accordo, il C++ non è certo
il C od il Pascal, quindi mi sarei anche potuto aspettare file di
dimensioni maggiori rispetto agli eseguibili ottenuti quando scrivevo
programmini per gli esami di Fondamenti di Informatica, ma... mezzo MB!
Forse sono io che sono stato un po' troppo lontano dal mondo della
programmazione, forse la domanda, come dicevo, è un po' ingenua, ma... è
NORMALE?
Oppure c'è qualche opzione del compilatore che devo settare?
Grazie e ciao,
Giulio.

 che ho attualmente) e ne è uscito un file di quasi mezzo MB!
Mi sembra un po' troppo. Sui 150 Kb è un valore più verosimile.
EMG

Oppure c'è qualche opzione del compilatore che devo settare?
Probabilmente la dimensione e` dovuta alle informazioni di debug, ci
deve essere una qualche opzione che permette di eliminarle.
Poi chiaramente dipende anche dalle librerie che vengono linkate...
Paolo
-----------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------

Poi chiaramente dipende anche dalle librerie che vengono linkate...
Non necessariamente.
Se compili questo:
#include    <stdio.h>
char       a[2000000];
int    main(void)
{
    a[100] = 1;
}
ti da' un exe di due mega.
Cioe' si alloca tutte le variabili in segmenti dati (non stack), e li mette
nell'exe.
Marco

>Oppure c'è qualche opzione del compilatore che devo settare?
Si, devi compilare togliendo -g e aggiungendo -O3 (N.B. O maiuscola,
forse basta O2): cosi' dovrebbe ottimizzare la grandezza del codice.
La cosa piu' importante, al di la' delle ottimizzazioni, e' che quando
linki devi aggiungere -s : questa opzione rimuove tutti i nomi dei
simboli che sono inclusi nell'eseguibile.
Ciao
RSte
rste79...@hotmail.com

Se compili questo:
Ok, ma dalla domanda mi sembrava di capire che la persona
avesse escluso un simile caso, anche perche` ci si riferiva
all'immagine su disco non all'occupazione di memoria a run time.
L'immagine su disco in molti casi poi non risente di tali situazioni
(ad esempio per dati non inizializzati).


all'immagine su disco non all'occupazione di memoria a run time.
Infatti e' proprio l'exe che e' di due mega.
L'exe sta sul disco, ovviamente.
Anche il BC++3.0, per quanto ne so, fa lo stesso.
Mentre il watcom mi pare di ricordare di no.
Sicuramente no, infine, il VC++ 6.0
Marco

all'immagine su disco non all'occupazione di memoria a run time.
Per dare ulteriori informazioni, l'unica variabile "seria" dal punto di
vista della dimensione è un vector<string> che però non ha una
dimensione predefinita (deve servire da buffer in cui inserire linee
lette da un file di testo). Non è inizializzato (posso inizializzarlo
anche se non ne conosco la dimensione?) ma penso che questo non
costituisca un problema in riferimento alla questione che ponevo.
Cmq, proverò le varie opzioni che mi avete consigliato... poi, se avrò
ancora problemi o no, vi saprò dire :)
Ciao,
Giulio.


Il DJGPP lo fa solo se si compila C++, mentre per il C non alloca nell'exe
lo spazio per le variabili non inizializzare (che mi sembra venga
automaticamente messo a 0 dal codice di startup). Lo std C++ dichiari
esplicitamente che gli oggetti globali devono essere inizializzati a zero
prima di ogni altra inizializzazione (3.6.2 della first edition 01/091998),
quindi prima di chiamare eventuali costruttori. Questo vale anche per i POD
e gli oggetti inizializzati con valori costanti e quelli inizializzati
vengono accomunati. Un'interpretazione puo' essere quella di non distinguere
fra oggetti inizializzati e non, gonfiando l'exe.
Certo che come soluzione mi sembra molto discutibile, tenendo conto che con
il vecchio sistema (azzerare nella routine di startup, come probabilmente fa
il VC++) si ottiene lo stesso risultato senza gonfiare l'exe, a meno che'
non ci siano altri requisiti da rispettare (tipo l'ordine di allocazione
rispetto alla definizione, ma non mi sembra che esista niente del genere).
Saluti, Alberto.

rispetto alla definizione, ma non mi sembra che esista niente del genere).
Infatti. Non capisco proprio perche' si debba gonfiare cosi' l'exe, ma
tant'e'.
Il VC++ alloca e azzera proprio a sartup, tanto piu' che se il programma non
entra in memoria te lo dice dopo averlo caricato.
E lo stesso mi pare facesse il watcom.
Boh....

il VC++) si ottiene lo stesso risultato senza gonfiare l'exe, 
In effetti pare molto discutibile anche a me...
Comunque BC++5.02 non gonfia l'eseguibile...
