gcc i exe

0

witam

korzystam z gcc 2.95 z Dev C++
(przy najlepszej optymalizacji)

1).
czy:

char* buf = new char [15] ;

zajmie w pliku exe mniej niz:

char buf[15] ;

??

2).
zaywalylem ze jesli w danej chwili wychodzi mi exe'k o rozmiarze powiedzmy:

44032 bajty

to podczas dodawania dalszego kodu rozmiar przez jakis czas utrzymuje sie pozniej sie zwieksza i znowu do jakiegos czasu sie utrzymuje ... tak skokowo
czy mozna zmusic ten kompilator aby tak nie robil? tzn aby produkowal pliki nie powiekszane o zadne zbedne bajty

pozdro

0

Ad1. Jeżeli w ogóle nie korzystasz ze zmiennych dynamicznych, kompilator może nie wrzucać do kodu menedżera obsługi tej pamięci.

Ad2. Rozmiary pliki wykonywalnych są zaokrąglane - zależnie od systemu i komplikatora od 16B do 4kB, i niewiele na to poradzisz.

0

<ort>Sprubuj </ort><ort>zooptymalizowac </ort>kompilacje (-O3).

0

Sprubuj zooptymalizowac kompilacje (-O3).

napisalem przeciez ze jest przy najlepszej optymalizacji

pozdro

0

najlepsza obtymilizacja to -0s i dodaj jeszcze usunoeci symboli debugera (chyba -s)

0

Wielkosc pliku wynikowego nie jest zaokraglana jak to ktos powyzej powiedzial do z gory okreslonych warosci [diabel] Jego skokowa wielkosc jest spowodowana przyjetym przez windows formatem plikow PE, ktory polega na podziale na sekcje, ktore musza byc wyrownywane i wszystko zalezy od ilosci tych sekcji i jak szybko sie zapelniaja(skokowy przyrost).

// ale mowa o gcc! linux! - ŁF

0

1.
-Os ani -O3 to wcale nie są najlepsze optymalizacje
Dlaczego?
-Os optymalizuje kod pod względem rozmiaru (daje najmniejsze pliki wynikowe)
-O3 optymalizuje pod względem prędkości wykonania

'Lepszość' jednej opcji od drugiej zależy tylko i wyłącznie od kryteriów przyjętych przez programistę :)

Łukasz: on pisał o gcc dla Windowsa.

1 użytkowników online, w tym zalogowanych: 0, gości: 1