Newsgroup: it.comp.lang.c++
Titolo: Dev-cpp: dimensione dell'eseguibile prodotto

Ciao a tutti, sto iniziando ora a studiare il C++ e come compilatori
dispongo sia del Borland C++ Builder 2006, sia del Dev-cpp.
Prendendo come esempio il solito e banalissimo "primo programma in
C++", tanto per intenderci quello che scrive in console il tipico
"Hello world!", ho notato una differenza smisurata nella dimensione
dell'eseguibile prodotto fra il Borland e il Dev-cpp.
Ovviamente il .cpp è:
#include <iostream>
using namespace std;
int main()
{
    cout << "Hello World!";
    cin.get();
    return 0;
}
Lo stesso identico file .cpp, compilato in Borland produce un exe da
21 Kb mentre compilato in Dev-cpp ne produce uno da ben 463 Kb!!
Immagino che due compilatori diversi producano binari diversi, ma
sinceramente 463 Kb per scrive "Hello world!" in console mi sembrano
veramente troppi!
Non che sia un reale problema, ma piuttosto una curiosità.
Ho cercato nelle opzioni di compilazione del Dev-cpp per trovare
qualcosa che giustificasse la cosa, ma non mi sembra di aver notato
nulla di strano.
Da cosa può dipendere questa enorme differenza?
Perchè Dev-cpp produce un exe così grande per un semplice COUT?
Grazie in anticipo a tutti.
uomoserio

 veramente troppi!
Probabilmente con Dev-Cpp utilizzi librerie statiche e quindi il tuo
programma contiene mezza libreria standard del C++.
Ciao,
Nicola

programma contiene mezza libreria standard del C++.
Io ho scaricato il Dev-cpp dalla sua homepage ed installato in
versione completa. Non saprei che librerie utilizza, ma immagino che
il problema sia proprio quello che hai esposto tu.
Eventualmente cosa devo impostare, nel Dev, per fare in modo che non
includa nell'eseguibile anche la libreria non utilizzata, e quindi che
produca eseguibili più "leggeri"?
Uomoserio

Devi andare in opzioni di compilazione, scheda ottimizzazioni, clicca
su linker e setta a "yes" la voce "comprimi l'eseguibile".
ciao.



Ho provato, grazie. In effetti comprimendolo l'eseguibile si riduce di
quasi la metà, ma rimane comunque enorme rispetto all'eseguibile
prodotto dal Borland con lo stesso .cpp.
Evidentemente non è una questione di compressione dell'eseguibile, ma
del suo contenuto.
Da cosa può dipendere la grande differenza?
Ricordo i dati: stesso identico .cpp
- Borland EXE 21 Kb
- Dev-cpp EXE 476 Kb (270 compresso)

 - Dev-cpp EXE 476 Kb (270 compresso)
Come ti è già stato detto, può darsi che nell'eseguibile Borland si 
utilizzino delle DLL esterne. Un modo per scoprirlo è cercare "dll" 
all'interno dell'eseguibile, con un editor binario.
E.

 - Dev-cpp EXE 476 Kb (270 compresso)
domanda: hai provato a togliere le info di debug?

domanda: hai provato a togliere le info di debug?
Si, già controllato, nessuna informazione di debug abilitata.
C'è da dire, però, che non conosco bene il Dev-cpp e può darsi che di
default sia abilitata qualche opzione che non considero e che causa il
lievitare dell'eseguibile.
Ovvio, non è una questione importante, posso tranquillamente usare il
Borland. Vorrei solo cercare di capire il motivo di questa differenza.

E.
Proverò a controllare....ma cosa devo cercare? Voglio dire...una volta
trovato "dll" all'interno dell'eseguibile, come mi accorgo se ci sono
libreire esterne, superflue o inutilizzate?
Grazie per l'interessamento. :-)
uomoserio



L'unica cosa è quella di compilare a manina. Porva anche l'utility
strip.exe presente nella cartella bin del dev. In effetti il dev è
solo un ide (scritto in delphi!) che utilizza in modo trasparente
tutti i comandi necessari per compilare il sorgente. Ti confesso che
tranne per qualche prova, ho sempre compilato attraverso il dev :(
Cercherò di rimediare, studiandomi questo manualetto:
http://www.network-theory.co.uk/docs/gccintro/index.html
Ti consiglio, comunque di rimanere con il gcc.
ciao.

 strip.exe presente nella cartella bin del dev. 
No, non è questo il problema. Io ho provato a ripetere le prove dell'OP, 
e questo non aiuta. Può darsi che il borland utilizzi delle DLL di 
windows, risparmiando sulle librerie statiche.
E.


Le DLL sono librerie dinamiche. Se utilizzi una DLL, il tuo eseguibile 
diventa più corto perché si appoggia su una libreria esterna. Questa 
libreria di solito si trova in C:\WINDOWS\SYSTEM32\*.DLL. All'interno 
dell'eseguibile deve essere specificato il nome della libreria dinamica, 
ovvero il nome del file esterno. Questo può essere qualcosa tipo 
"winmm.dll". Per verificare questa ipotesi dovresti cercare 
nell'eseguibile BORLAND se al suo interno trovi il nome di un qualche 
file "*.dll". Questo spiegherebbe come mai quell'eseguibile è più corto. 
Conoscendo poi il nome delle DLL usate dall'eseguibile BORLAND, si può 
cercare di capire se lo stesso effetto si può ottenere con Dev-Cpp.
E.

 Perchè Dev-cpp produce un exe così grande per un semplice COUT?
Nelle FAQ c'è scritto:
C++ programs using the Standard Template Library (ie/ #include 
<iostream>) cause a large part of the library to be statically linked 
into the binary. The need to statically link the stdc++ into the binary 
is two fold. First MSVCRT.dll does not contain C++ stdlib constructs. 
Second the legal implications of generating a libstdc++.dll are 
restricted by the licensing associated with the library. If you wish to 
keep your file size down use strip to remove debugging information and 
other verbatim found in the binary.
strip --strip-all SOMEBINARY.exe

strip --strip-all SOMEBINARY.exe
Già provato, ma il risultato è lo stesso che si ottiene utilizzando la
funzione di compressione dell'eseguibile da dentro il Dev.
270Kb , che sono comunque troppi rispetto ai 21Kb dell'eseguibile
Borland.
Comunque ho capito che è una questione di librerie dinamiche.
Evidentemente il Borland sfrutta delle dll presenti nel sistema ed
evita di inserire mezza libreria nell'exe.
Grazie comunque per la segnalazione delle Faq.
uomoserio