Newsgroup: it.comp.lang.c++
Titolo: DJGPP: piu' grossi di te non li fa nessuno!!

Vediamo di spiegare meglio questo subject :-)
Sto scrivendo un programma che, almeno nella sua forma primordiale, non era
certo un buon esempio di programmazione (non che adesso... ); il primo
listato era lungo 6 kbyte e la compilazione dava origine ad un eseguibile di
170 Kbyte, mi sono detto: cosa pretendi hai scritto un programma in un solo
sorgente senza certo badare agli sprechi, e' normale!!
Poi cosi', per curiosita', ho deciso di veder quanto fosse grande
l'eseguibile del sorgente piu' stupido del mondo, solo 119 byte:
#include <iostream.h>
    int main()
        cout << "Hello World \n";
        return 0;
    }
e con sorpresa ho ottenuto un eseguibile di 155 kbyte!!!! Siccome credo di
aver fatto la scoperta dell'acqua calda :-) qualcuno mi spiega cosa sta
succedendo? che soluzioni devo adottare (leggi: quali opzioni di
compilazione devo utilizzare) per ridurre la grandezza degli eseguibili? I
comandi che uso per compilare sono:
gcc -c miofile.cc   (crea il file miofile.o)
gxx -o miofile.exe miofile.o (crea l'eseguibile)
e credo siano ridondanti ( sulla barra del titolo della finestra di M$-DOS
leggo due volte il nome dell'assemblatore, il che mi sembra strano).
So che la classe iostream e' piuttosto pesante in quanto a velocita' di
esecuzione, ma e' lei la causa anche della grandezza spropositata dei
sorgenti? tra l'altro non credo di avere scelta perche' ho la necessita' di
compilare questo programma tanto sotto DOS che sotto Unix.
Concludo questo papiro con un'ultima domanda: gli eseguibili creati con il
DJGPP non dovrebbero essere retrocompatibili sino all'8086 giusto? a parte
procurarmi un vecchio compilatore (che comunque credo sia la soluzione piu'
adatta), con quali mezzi posso raggiungere questa retrocompatibilita'?
Adesso ho veramente finito!!
ciao e grazie a chiunque rispondera'.
nIcO

 adatta), con quali mezzi posso raggiungere questa retrocompatibilita'?
Credo sia l'unica soluzione.
EMG

comunque aumentano poi molto lentamente all'aumentare del codice.
Oddio, non ne sarei sicuro. Un mio programma che compilato con il Borland
occupava circa 600K, col DJGPP arriva a 1 mega e mezzo.
Pero' si guadagna molto in velocita'.
Marco

adatta), con quali mezzi posso raggiungere questa retrocompatibilita'?
Decidere di caso in caso se effettivamente hai bisogno di questa
retrocompatibilita`.
Se si allora usa qualche vecchio Turbo C, oppure un recente Borland
C++ (es. la 5.02). Perdi compatibilita` UNIX a livello di makefile, ma
puoi disattivare le ottimizzazioni per 386/486/Pentium e generare
codice 16 bit.
Nota, ne il Turbo C ne il Borland C++ 5.02 ne la libstdcxx.a (2.81)
sono completamente ISO C++ compatibili, ed alcune caratteristice
recenti del C++ non sono implementate.
Il Turbo C non supporta i template.
Quindi o DJGPP (Compatibilita` Unix 100%, 8086 0%) oppure Borland
(Comp. Unix poca, 8086 100%)
PS: E` uscito il nuovo djgpp (quello prendilo).
-- 
Gargamella alias Massimo Lauria
"Non e` bello cio` che e` bello, ma e` bello cio` che piace... a me!"

 wrote:
E` normale...
esiste del codice nascosto che serve a far funzionare i
programmi che scrivi. Questo codice costituisce il
supporto a tempo di esecuzione (ad esempio il
codice di start-up) e che rientra in quelle cose che
stanno dietro le quinte di un linguaggio (e non solo).
A questo devi aggiungere il codice della libreria iostream
che tu utilizzi (almeno in parte) eseguendo la "cout << ...."
Insomma ci sono un sacco di cose nascoste dietro
il tuo codice che servono a farlo funzionare. Inoltre
nell'exe ci potrebbero essere nascoste informazioni di debug
che normalmente vengono eliminate settando una qualche
opzione.
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

Col turbo pascal 7.1 ho scritto questo:
begin
    writeln('Ciao mondo!');
    readln
end.
Risultato? 2,2kb.
Non ho il turboC, ma penso che resti in linea col turbo pascal,
(qualcuno smentisca o confermi).
Con il DJGPP ho il tuo stesso problema! Se qualcuno sa
come ottenere eseguibili piccoli con il DJGPP mi avverta!
Ho sentito che l' Lccwin32 si mantiene sotto i 40kb anche nelle
applicazioni GUI, ma l' ho appena scaricato e non lo so ancora
usare. E' freeware, comunque, lo trovi in rete!
Ciao!

 Pero' si guadagna molto in velocita'.
Beh, questo è già un buon motivo per preferirlo (oltre al fatto che è
gratis), no?
EMG

 recenti del C++ non sono implementate.
Sembra che la nuova versione 2.95 della libstdcxx sia già molto meglio.
EMG

dal codice (-s)?
Si, tolto tutto di debug e messo O3.
Non mi spiego questa enormita' del codice. In effetti su tutti i programmi
che ho ricompilato la dimensione e' davvero esagerata.
C'e' da dire pero' che io di ++ uso solo il commento //.... dunque
probabilmente il linker del borland elimina tutta la gestione degli stream e
cose simili, mentre il linker del DJGPP no.
Almeno credo.
Marco

Sembra che la nuova versione 2.95 della libstdcxx sia già molto meglio.
Non avevo ancora letto l'annuncio del nuovo djgpp (e librerie) quando
ho composto il messaggio.


cose simili, mentre il linker del DJGPP no.
Hai strippato l'eseguibile dopo il linking ?
strip nomefile
-- 
Roberto Gerola
Email: 
robert...@penguinpowered.com
WWW: 
http://www.penguinpowered.com/~The_Cpp_Compass

strip nomefile
No... non e' che mi ci mette 512K di stack??
Provero'
Marco

Provero'
Provato. Da 1.4M a 820K.
Grazie per la dritta, credevo che disabilitando il debugging dal rhide si
toglievano tutti i simboli, invece serviva 'sto strip (o il -s, come diceva
EMG).
Marco

 Quali?
Compilatori C non lo so. Perņ, ad esempio, il Clipper lo permette.
EMG