Newsgroup: it.comp.os.linux.development
Titolo: G++ 3.0 ed eseguibili very fat

In questi giorni sto preparando un progetto, e sono ideciso se farlo
in C o in C++, e spero che qualcuno di voi mi possa dare alcune
conferme (o smentite) [PS. non ditemi il C++ e' meglio del C (vedi
altro thread), io preferirei il C++, ma devo anche scontrarmi con la
realta'!]
1) Dimensioni degli eseguibili
Ho fatto alcuni piccoli programmini di test, e mi ha colpito molto
sfavorevolmente il fatto che il nuovo g++ genera eseguibili un pelo
piu' grossi del 2.95: 
-rwxr-xr-x    1 raf      raf          8150 nov  1 15:10 var-2.95*
-rwxr-xr-x    1 raf      raf        271052 nov  1 15:11 var-3.0*
-rw-r--r--    1 raf      raf           596 nov  1 15:09 var.cc
Non mi sembra molto bello... Questo lo fa (soprattutto) in presenza di
template.
Avete notizie in merito? Se e' previsto uno snellimento?
Oppure esistono degli switch per questo? Io non ne ho visti, ma
magari...
Cercando con google, mi sono perso... e non ho trovato nulla di utile.
[Questo puo' essere considerato OT, quindi potete rispondermi anche in
email]
2) Avrei anche la necessita' di portarlo sotto win.
Sapete se il codice generato con il mingw32 (o cygnus...) puo' essere
usato senza problemi dal vc++ (quale dipende, il 6 non supporta
decentemente i template)? O usano ABI differenti per il C++? Per il C
so che non ci sono problemi di sorta.
-- 
+---- | Un OS per domarli, Un OS per trovarli,             |  -o)
+---+ | Un OS per ghermirli e nel buio incatenarli         |  /\\
 O  | | Nella terra di Redmond, ove l'ombra cupa scende... | _\_V
                    raffaele punto salmaso presso libero punto it

 magari...
non e' che compila con static linking di default?
cioe', invece di chiamare libstdc++.so.XXX, si linka con libstdc++.a?
comunque, per snellire gli eseguibili, io uso (su Intel)
-fomit-frame-pointer -fgcse -frerun-loop-opt 
-fcse-follow-jumps -fcse-skip-blocks 
-frerun-cse-after-loop -s
se poi non usi eccezioni e rtti:
-fno-rtti -fno-default-inline -fno-exceptions
magari un info gcc ti dara' piu' informazioni

magari un info gcc ti dara' piu' informazioni
Eh, il problema e' trovarle in mezzo a tutte le altre (insieme a tutte
le altre attivita')


 -rwxr-xr-x    1 raf      raf        271052 nov  1 15:11 var-3.0*
Qui`  c'e` qualcosa  che non  va. Il file  compilato con  il gcc3  e` 30
volte  piu` grande  dell'altro! Anch'io ho  registrato un  aumento della
dimensione dei  file, ma  contenuto entro  il 6%-7%. Non  e` che  uno e`
"strippato", mentre l'altro e` compilato con -g? size che cosa dice?
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Porc i' mond che cio' sott i piedi!
V. Catozzo

 le altre attivita')
be', ti dovrebbero bastare le opzioni di ottimizzazione e linkaggio... 
sono poche centinaia di righe, mica milioni

 C++? Per il C so che non ci sono problemi di sorta.
Avevo da qualche parte un link per una STL multipiattaforma che compila 
tranquillamente con una ventina di compilatori, inclusi gcc, Microsoft 
C++ e Borland C++. Se lo ritrovo lo posto

C++ e Borland C++. Se lo ritrovo lo posto
No. Non e' la STL (che tra l'altro non uso). E' proprio il fatto di
compilare col vc++ e poter riusare la dll (o lib) con mingw32 o cygnus
(oppure il contrario) senza problemi di name mangling o altre
incompatibilita' [non ho ancora avuto il dis-piacere di usare win per
compilare]


 -rw-r--r--    1 raf      raf           596 nov  1 15:09 var.cc
mmmmh... e se provi a stripparli che succede? (strip var-3.0)
-- 
addio, e grazie per tutto il pesce

per compilare]
Il name mangling *è* un problema. Ogni compilatore lo fa a modo suo: 
nessun innocente, nessun colpevole. Nemmeno g++ rispetta completamente 
lo standard *proposto* nella specifica ufficiale
Lo schema di mangling di Microsoft C++ non è documentato ufficialmente, 
ma non ufficialmente lo è molto bene (non sto a darti il link, perchè 
non potresti farci granchè, a parte decorare i nomi a mano, e ti 
assicuro che non è questo gran divertimento), e difatti mi stavano 
arrivando voci non confermate di un'imminente patch per gcc (non solo 
per g++ ma anche as, che non considera nemmeno *validi* i nomi decorati 
da MSC++, e forse anche dlltool e altri)
Più in generale e più terra-terra: non esporre mai funzioni C++ 
direttamente, usa extern "C" e la vita ti sorriderà