Aufgeblähte C++ Programme !?



  • #include <tchar.h>
    #include <iostream>
    
    int _tmain()
    {
      std::cout << "Hello world";
    }
    

    Ergibt bei mir (VS2005) im Release:
    7.680 bytes (shared CRT)
    110.592 bytes (static CRT)



  • GPC schrieb:

    Stöffel schrieb:

    @GPC Ja, du hast recht, wenn ich <iostream> nicht einbinde, ist das Programm nur noch 15kB gross. Aber wieso kopiert der Compiler die ganze iostream Library in das .exe? Wenn ich "Hello World" ausgebe, benutze ich doch nur einen Bruchteil der Library, nicht?

    Richtig, interessiert den Compiler aber nicht. Der kopiert per #include einfach die komplette iostream + deren Abhängigkeiten (string usw. ) in deine Datei rein.

    aber was soll das? es ist doch absolut sinnlos, irgendwas in die exe zu packen, was nie verwendet wird 😕



  • net schrieb:

    GPC schrieb:

    Stöffel schrieb:

    @GPC Ja, du hast recht, wenn ich <iostream> nicht einbinde, ist das Programm nur noch 15kB gross. Aber wieso kopiert der Compiler die ganze iostream Library in das .exe? Wenn ich "Hello World" ausgebe, benutze ich doch nur einen Bruchteil der Library, nicht?

    Richtig, interessiert den Compiler aber nicht. Der kopiert per #include einfach die komplette iostream + deren Abhängigkeiten (string usw. ) in deine Datei rein.

    aber was soll das?

    Ich nehme an, es war den Compiler-Entwicklern egal (zumindest denen beim VC und GCC), dass die exe dann halt größer wird. Ich meine hey, 100-500 kb, was ist das schon? Mich hätt's auch nicht gejuckt, wenn ich vor der Entscheidung gestanden hätte.

    es ist doch absolut sinnlos, irgendwas in die exe zu packen, was nie verwendet wird 😕

    Ja, sicher. Aber ich denke dieser Aspekt wird nur in Bereichen relevant, wo es wirklich auf Platz ankommt. Und da wird vermutlich nicht der VC oder die GCC eingesetzt und auch nicht iostream dazugelinkt^^

    @Stöffel
    Welche Version vom MinGW hast du denn? Noch 'ne 3.x? Die 4.0 ist in dem Punkt nämlich deutlich besser (und die Programme sind meist schneller)



  • GPC schrieb:

    @Stöffel
    Welche Version vom MinGW hast du denn? Noch 'ne 3.x? Die 4.0 ist in dem Punkt nämlich deutlich besser (und die Programme sind meist schneller)

    Ja, die Version ist 3.4.2. Aber wieso fragst du nach der Version der MinGW? Ich dachte das sind nur die Library files. Reicht es wenn ich den Compiler ersetzte, oder muss ich die Library auch erneuern?
    Die Optimierungen -Os -s haben übrigens das .exe um ein ganzes kB geschrumpft. WOW! 😃



  • Stöffel schrieb:

    Ja, die Version ist 3.4.2. Aber wieso fragst du nach der Version der MinGW? Ich dachte das sind nur die Library files. Reicht es wenn ich den Compiler ersetzte, oder muss ich die Library auch erneuern?

    du musst einen anderen linker nehmen. normalerweise muss der erkennen was unbenutzt ist und das dann draussen lassen.
    :xmas2:



  • Stöffel schrieb:

    Die Optimierungen -Os -s haben übrigens das .exe um ein ganzes kB geschrumpft. WOW! 😃

    Hm, du hast sicherlich -O2 oder -O3 dringelassen, hm? Mach das mal raus und schau dann, was passiert.
    Bei mir hat -s nämlich immer ziemlich viel gebracht.



  • Ne aktuelle version vom MinGW dürfte auch gut tun, schau mal auf der Homepage http://www.mingw.org



  • Lass mal strip drueberlaufen. Vielleicht bringt es ja noch ein bissle

    gruss
    v R



  • GPC schrieb:

    Stöffel schrieb:

    Die Optimierungen -Os -s haben übrigens das .exe um ein ganzes kB geschrumpft. WOW! 😃

    Hm, du hast sicherlich -O2 oder -O3 dringelassen, hm? Mach das mal raus und schau dann, was passiert.
    Bei mir hat -s nämlich immer ziemlich viel gebracht.

    Jetzt wo ich über ein batch File kompiliert habe, ist das .exe tatsächlich auf 260kB geschrumpft. Vom Dev-C++ aus hatte das irgendwie nicht geklappt. Ich werde dann mal versuchen den Compiler zu erneuern. Danke für die Hilfe.



  • Jetzt habe ich mal ein "Hello World" in VC++ 2005 gemacht. Nur 8kB!? 😮



  • Stöffel schrieb:

    Jetzt habe ich mal ein "Hello World" in VC++ 2005 gemacht. Nur 8kB!? 😮

    Es dürfte klar sein, dass der MS Compiler (da ja für Windows entwickelt) ziemlich viel rauskitzeln kann und außerdem so gut wie nichts statisch dazugelinkt wurde.



  • Wie aus meinem letzten Posting ersichtlich ist, erreicht man die 8 KB (bei verwendung der STL) *nur*, wenn man gegen die DLL-version der CRT linkt!



  • wenns schon auf die letzten Bytes ankommt, bringts der Vergleich von dynamisch-gelinkten Programmen gar nicht.

    Jochen Kalmbach schrieb:

    #include <tchar.h>
    #include <iostream>
    	
    int _tmain()
    {
      std::cout << "Hello world";
    }
    

    Ergibt bei mir (VS2005) im Release:
    7.680 bytes (shared CRT)
    110.592 bytes (static CRT)

    hm, wenn ich mit dem gcc mit -Os -s -static kompiliere, wirds immer noch 9x so groß. Ist bei "static-CRT" wirklich alles drin?

    Aber man müsste das schon präziser vergleichen... C++-hello world != C++ mit exceptions und destruktoren



  • DrGreenthumb schrieb:

    hm, wenn ich mit dem gcc mit -Os -s -static kompiliere, wirds immer noch 9x so groß. Ist bei "static-CRT" wirklich alles drin?

    Ja. Bei der VC8 CRT sind sogar noch wesentlich mehr Checks und überprüfungen drin als bei VC6-7.1.

    Der MS-Linker ist sehr intelligent und schmeisst alles raus, was nicht direkt verweisen wird. Das hat übrigens mit dem Compiler nichts zu tun (so wie hier teilweise beschrieben wurde).
    Auch kann der MS compiler ein sog. "Full-Program Optimazation" machen... da fügt erst den *Linker* einzelne Methoden als inline ein...
    Siehe auch "Profile Guided Optimization".


Anmelden zum Antworten