#include <iostream> 
int main(void)
{
   std::cout << "Hello world!\n";
   return 0;
}

Jetzt würde ich gerne euren Compiler + Flags + IDE wissen. Und dazu eben die Exe-Größe. Ich werde hier wahrscheinlich auch ne kleine Liste zusammenstellen.
Ich hab nämlich das Gefühl das was mit meiner IDE nich stimmt

nt0r Code::Blocks → g++ → 457kB

Ich denke, dass du die Basis-Bibliotheken statisch einkompiliert hast.

> Ich hab nämlich das Gefühl das was mit meiner IDE nich stimmt

Ich denke, dass du die Basis-Bibliotheken statisch einkompiliert hast.

Wenn diesem so ist : Was kann ich dagegen tun ?

TheUndeadable schrieb:

> Ich hab nämlich das Gefühl das was mit meiner IDE nich stimmt

Ich denke, dass du die Basis-Bibliotheken statisch einkompiliert hast.

Wenn diesem so ist : Was kann ich dagegen tun ?

Nix! (vielleicht geht das dynamisch, aber beim MinGW würde ich das lassen)
Bei MSVC kannst du sie dynamisch linken (wenige KB, die Runtime ist auf vielen Windows-Rechnern) oder statisch (immer noch deutlich kleiner als beim MinGW). Ich würd's allerdings einfach so lassen. Bei größeren Programmen macht das eh nicht viel aus.

3 KB mit Visual C++ 2010 unter extrem Konfiguration. Die dir in diesem Fall zur Verfügung stehende C++-Standard-Bibliothek besteht aus einem File iostream welches ungefähr den folgenden Inhalt hat:

void __stdcall mainCRTStartup()
{
    extern int main();
    main();
}

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

namespace std
{

    struct
    {
        static int strlen(const char *buffer)
        {
            int len = 0;
            while (*buffer++)
                ++len;
            return len;
        }
        void operator<<(const char *buffer) const
        {
            WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE),
                buffer, strlen(buffer), 0, 0);
        }
    } cout;

}

Merke: Eine brauchbare Standard-Library braucht ein paar KB Speicher. Das sollte heute kein Problem mehr sein

MfG

Grüssli

Merke: Eine brauchbare Standard-Library braucht ein paar KB Speicher. Das sollte heute kein Problem mehr sein

MfG

Liegt die Library jetzt in dll's oder is sie statisch drin?
Mich würde es nämlich sehr verwundern wenn ein allgemein anerkannter Compiler wie der g++ einfach denkt : "Uiii ein include! Packen wir alles rein was wir haben , oder Linker?" Und eben nicht nach verwendetem filtert.
Kein Mensch kann mir erzählen , dass nur die stream-Klassen schon 450 kB brauchen.Mit printf sind es ja auch nur 7kB.

PS: Mit dem Upx bekomm ich die größe auf 127kB unter , aber ich glaub das ist nicht gut für die Performance

nt0r schrieb:

Kein Mensch kann mir erzählen , dass nur die stream-Klassen schon 450 kB brauchen.Mit printf sind es ja auch nur 7kB.

Nur die Stream-Klassen alleine brauchen schon 450 KB. Bin ich jetzt ein Unmensch? Im Ernst: iostream besteht aus so vielen von einander abhängigen Templates, da ist es kein Wunder, dass dort irgendwie ein paar Hundert KB zu Stande kommen. Und bei cstdio mit printf ist es auch logisch, dass es weniger braucht. Ist ja auch viel weniger komplex und bietet nicht mal ansatzweise so viele Möglichkeiten. Schreib dir selbst eine (brauchbare!) iostream-Library (oder schau dir STLport an) und du wirst merken, dass es nicht so einfach ist

MfG

Im Ernst: iostream besteht aus so vielen von einander abhängigen Templates, da ist es kein Wunder, dass dort irgendwie ein paar Hundert KB zu Stande kommen. Und bei cstdio mit printf ist es auch logisch, dass es weniger braucht. Ist ja auch viel weniger komplex und bietet nicht mal ansatzweise so viele Möglichkeiten. Schreib dir selbst eine (brauchbare!) iostream-Library (oder schau dir STLport an) und du wirst merken, dass es nicht so einfach ist

MfG

Haha Da merke ich , dass ich der Sohn von dem Urprogrammierer bin der noch mit Lochkarte gecodet hat und sich tierisch aufgeregt hat wenn sein Fortran-Compiler zu groß war.
Ich finde es bloss sehr schade , dass ich in Code::Blocks (mit keinem einzigen Compiler) eine kleine exe(<457kB) hinbekomm , in der nur das drin ist , was gebraucht wird. Der VisualC++-Compiler kann das ja auch (8kB).
MfG nt0r

EDIT: Mir ist grade eben was aufgefallen : Wenn ich mein Programm manuell über cygwin bzw. g++ kompiliere (g++ main.cpp -s -o tested.exe) , dann ist die Größe durch das strippen verringert. Wenn ich beim Code::Blocks das anschmeiße tut sich nichts. Weiß jemand genauer bescheid?

Kein Mensch kann mir erzählen , dass nur die stream-Klassen schon 450 kB brauchen.

Doch, klar. Da hängt so einiges dahinter, was nicht unbedingt offensichtlich ist, z.B. die locale-Bibliothek.

nt0r schrieb:

Ich finde es bloss sehr schade , dass ich in Code::Blocks (mit keinem einzigen Compiler) eine kleine exe(<457kB) hinbekomm , in der nur das drin ist , was gebraucht wird. Der VisualC++-Compiler kann das ja auch (8kB).

Wie gesagt, VC++ linkt die C++-Runtime normalerweise dynamisch, MinGW dagegen statisch. Das hat durchaus Vorteile, so benötigen MinGW-Executables keine Varianten von msvcrXX.dll und msvcpXX.dll um zu funktionieren. Du kannst zwar auch mit MinGW dynamisch linken und damit die Größe ebenfalls auf 8 KB drücken, aber dann müsstest du libstdc++-6.dll mitliefern.
Das ist auch nicht besser.

Wenn dir was an Executablegrößen liegt, kannst du auf Standard-C++-Streams verzichten. Das erfordert aber natürlich, dass du mindestens gleichwertigen Ersatz dafür hast (cstdio zählt nicht dazu).

nt0r schrieb:

PS: Mit dem Upx bekomm ich die größe auf 127kB unter , aber ich glaub das ist nicht gut für die Performance

Mit Performanz hat das nur sehr begrenzt zu tun, aber ein großer Teil der Antivirus-Software stuft UPX-gepackte Executables als verdächtig oder gleich als Schadsoftware ein. Spätestens nach der 1000sten Nutzerbeschwerde oder nachdem dein Server "zu deiner eigenen Sicherheit" vom Netz genommen wurde, weil der Routinescan Schadsoftware auf deinem Webspace gefunden hat, hast du darauf keine Lust mehr.
Laufzeitgepackte Executables haben auch andere kleinere Probleme, z.B. dass jede Programminstanz eine eigene Kopie der entpackten Binary im Speicher hält.

nt0r schrieb:

Wenn ich beim Code::Blocks das anschmeiße tut sich nichts.

Weil -s für das Release-Target bereits standardmäßig aktiviert ist.

Wie gesagt, VC++ linkt die C++-Runtime normalerweise dynamisch, MinGW dagegen statisch.

Aber auch, wenn man mit VS (ich hab hier VS 2008) statisch linkt, ist der Unterschied gewaltig. Für

#include <iostream>

int main()
{
	std::cout << "Hello World\n";
}

ergeben sich mit g++ (3.4.5 mingw special) 477 KB, mit VS (cl - Version 15.00.30729.01) 96 KB, jeweils ohne irgendwelche Optimierungsschalter einfach von der Kommandozeile aus aufgerufen.

Vlt hängt MinGW irgendetwas per Default dran, was MSC nichtmacht? Irgendwelche Symbole?

Ja, Symbolnamen. Fairerweise muss man beim GCC mit -s linken.

Und beim GCC wird die (schwergewichtige) locale-Bibliothek vollständig mitgelinkt, auch wenn die nur in Teilen gebraucht wird (weil sich alles in der gleichen Objektdatei befindet).
Bei MSVC erhöht sich die Executablegröße gleich nochmal, wenn man statt "Hello World!" z.B. 3.14 ausgibt, da scheint das also etwas feinkörniger zu sein.

Ich frage mich, ob sich der GCC es gefallen ließe, wenn man libstdc++ und libgcc mit aktivierter LTO linken würde.
Damit könnte nicht benötigtes herausgeworfen werden, aber man müsste diese Bibliotheken erst einmal mit -flto neu bauen. Wer also mal Lust hat...

Du bist herzlich aufgerufen, ein anderes Beispiel (C++ wohlgemerkt, bei reinem C-Code erstellt der GNU-Compiler kleinere Dateien) zu posten, bei dem g++ eine kleinere exe - Datei erzeugt als cl.

Selbes Beispiel, unter Linux kompiliert:

#include <iostream>

int main()
{
    std::cout << "Hello World\n";
}

[ethon@Slaybook ~]$ g++ -Os -s -o hello hello.cpp
[ethon@Slaybook ~]$ size hello
text data bss dec hex filename
1817 600 296 2713 a99 hello

ca 5kb.
Also schieben wir es mal lieber auf den Mist den MinGw macht und nicht g++, ok?

Edit: Upps, .exe überlesen ...

Bei mir kommt übrigens mit -Os und strip exakt 5000 Bytes raus. Na ja - ist auch Linux und dynamisch gelinkt.

Also sagen wir mal, dass gcc prinzipiell erst mal kleine Binaries erzeugen kann. Dann wäre die Schuld entweder in den Compileroptionen oder in dem Windows-Port zu suchen.

Ich schaue mir gerade Gimp Plugins unter Windows an und entwickele dazu eine Klasse unter Codeblocks. Mein Mini-Plugin (Plugins unter Gimp sind EXE Dateien) belegt mit allen gerade mal 70 kByte in der Debug Version.

Hmm, merkwürdiges Problem.

Ich schaue mir gerade Gimp Plugins unter Windows an und entwickele dazu eine Klasse unter Codeblocks. Mein Mini-Plugin (Plugins unter Gimp sind EXE Dateien) belegt mit allen gerade mal 70 kByte in der Debug Version.

Naja, die müssen ja fast dynamisch gelinkt werden.