4. EasyWindow

EasyWindow

  • D

    Ich hab mal vergleichsweise Kompiliert:

    Hello World mit MinGW 3.4.5 (mingw-vista special), auf Windows XP Sp3 (Release-Mode)

    #include <stdio.h>

int main()
{
    char STR[] = "Hello, World!";

    printf("%s\n", STR);

    return 0;
}

    => 5,5 KB

    #include <stdio.h>
#include <string>

int main()
{
    std::string STR = "Hello, World!";

    printf("%s\n", STR.c_str());

    return 0;
}

    => 47KB

    #include <iostream>
#include <string>

int main()
{
    std::string STR = "Hello, World!";

    std::cout << STR << std::endl;

    return 0;
}

    ⚠ => 240KB!

    Es sind doch deutliche unterschiede in der Binärgröße zu beobachten, je nach verwendetem STL-Part. Allerdings ist die Größenzunahme nicht so massive wie von
    Nanyuki beschreiben, zumindest auf meinem System nicht.

    Ein Unterschied von 5KB zu 240KB! Für die Verwendung von std::string, std::cin, std::cout

    G-DC!

    0
  • A

    Und du willst uns jetzt genau was damit sagen? 🙄

    0
  • N

    Meine Angaben bezogen sich auf gcc 4.3.2.

    Ich hab mal alle Einbindungen von sstream aus EasyWindow entfernt und mit gcc 4.4.1 mit -Os kompiliert. Damit schrumpft die DLL von 826 KB auf 246 KB, was mir die Sache schon deutlich sympathischer macht.
    Falls gcc 3.4.5 generell kleineren Code erzeugt, könnte man diese Version auch zum Kompilieren der endgültigen Version der Bibliothek in Erwägung ziehen. Dass evtl. langsamerer Code erzeugt wird, ist in diesem Falle ja völlig irrelevant.

    0
  • A

    Hust:

    Visual Studio 2008 Professional, Release-Mode, statisch gelinkte CRT, C-Compile-Modus:

    #include <stdio.h>

int main() {
	char str[] = "Hello, World!";
	printf(str);
}

    →52KB

    C++-Compile-Modus (mit cstdio : 52KB)

    Mit Quellcode:

    #include <iostream>
#include <string>

int main() {
	std::string str = "Hello, World!";
	std::cout << str;
}

    →102KB

    Angesichts der vielen Vorteile von basic_ostream<> und basic_string<> ist dieser Preis wirklich sehr sehr milde.

    Falls gcc 3.4.5 generell kleineren Code erzeugt, könnte man diese Version auch zum Kompilieren der endgültigen Version der Bibliothek in Erwägung ziehen. Dass evtl. langsamerer Code erzeugt wird, ist in diesem Falle ja völlig irrelevant.

    Wohl kaum. Platzhirsch auf Windows für produktive Umgebungen bleibt Visual Studio. Am besten ist es, man kompiliert es selber und stellt die spezifischen Settings (SLN-Datei, Makefile usw.) bereit.

    0
  • D

    Artchi schrieb:

    Und du willst uns jetzt genau was damit sagen? 🙄

    Schlecht geschlafen? Leg dich nochmal hin und ruh dich ein wenig aus.

    G-DC!

    0
  • D

    Ad aCTa schrieb:

    Hust:

    Was der Bauer nicht kennt isst er nicht, oder so.

    Ad aCTa schrieb:

    Platzhirsch auf Windows für produktive Umgebungen bleibt Visual Studio.

    Ich halte von diesen sendungsbewussten Pauschalaussagen wie VS ist the Best nicht besonders viel, schon mal einen RISC Compiler programmiert? Ich auch! Dann wird dir auch klar sein was ein "Guter Compiler" ist und was nicht. Kein Zweifel Microsoft hat seine Hausaufgaben gemacht, andere aber auch! Siehe Borland C++, aber es gibt auch noch andere (will hier keinen Flame auslösen). Es kommt immer darauf an was man erreichen will und da ist VS nicht immer the Best, und sicher nicht Platzhirsch auf Windows für Produktivumgebungen. Ausser ich möchte mir schnell mal ein paar Buttons zusammenklicken... ups. da haben wir ja auch noch Borland C++.

    Und weils mir aufgefallen ist

    #include <stdio.h>

int main() {
    char str[] = "Hello, World!";
    printf(str);
}

    VS mit spielereien => 52KB
    GCC ohne spielereien => 5,5 KB

    Damit ist deine Aussage "Platzhirsch" evtl. so nicht haltbar... ausser du hast dich verschrieben, was mir eher der Fall zu sein scheint.

    So und damit wir uns alle wieder gut fühlen, wünsche ich euch noch einen schönen Advent!

    G-DC!

    0
  • M

    Also sagt mal...
    Wenn es hier um Anwendungen für Windows geht (was es offensichtlich tut). Was und wen interessiert es, ob ein Programm nun 100k oder 5k auf der Festplatte belegt? Das ist doch heutzutage sowas von egal!

    0
  • A

    DeepCopy schrieb:

    Artchi schrieb:

    Und du willst uns jetzt genau was damit sagen? 🙄

    Schlecht geschlafen? Leg dich nochmal hin und ruh dich ein wenig aus.

    Ich warte immer noch auf eine Antwort. Was mein Schlaf mit dieser Diskussion zu tun hat, will sich mir durch deinen Beitrag in keiner Weise erschließen.

    0
  • A

    Maxi schrieb:

    Also sagt mal...
    Wenn es hier um Anwendungen für Windows geht (was es offensichtlich tut). Was und wen interessiert es, ob ein Programm nun 100k oder 5k auf der Festplatte belegt? Das ist doch heutzutage sowas von egal!

    Mein Reden. Die Diskussion ist lächerlich. Zumal die C-Funktionen in keiner Weise mit dem C++-IOStreams vergleichbar sind. Man nutzt Features, wie Typsicherheit, Bufferoverflow-Sicherheit usw. und da kann man eine größere EXE in Kauf nehmen.

    0
  • D

    Auch wenn das ganze jetzt zu OT wird.

    Maxi schrieb:

    Wenn es hier um Anwendungen für Windows geht (was es offensichtlich tut). Was und wen interessiert es, ob ein Programm nun 100k oder 5k auf der Festplatte belegt? Das ist doch heutzutage sowas von egal!

    Klar da hast du recht wenn du nur die std. Apps betrachtest. Aber hast du schon mal einen Blick über den Tellerrand gewagt? Da gibt es COM besser DCOM und wenn du in so in einem großen Firmennetzwerk denkst dann "Gute Nacht", wenn du alles lokal als InprocServer (.dll) hast, gut - remote sieht das schon anders aus. Ich verwende die ATL alleine deshalb schon nicht weil die Alleine rund 40-50 KB schluckt, volle Kontrolle incl. Ich gebe zu das ich std::io nocht nicht im Backend brauchte (dafür habe ich was anderes) d.h. meine Überrschung.

    @Artchi: Siehe, es erschließt sich Dir nur noch nicht (oder du willst es so haben) weil du einfach nicht ausgeschlafen hast, wenn du den Thread aufmerksam von Anfang an hättest dann wäre Dir Informationswert meines Postings sicher aufgefallen, es ging dabei um die mögliche Reduktion der Lib, wieviel mit welchem Compiler. Du weist doch was ein Compiler ist oder, den Beleidigten spielen macht dich nicht interessanter.

    Schönen Advent
    G-DC!

    0
  • A

    Auch wenn das ganze jetzt zu OT wird.

    Naja, mehr oder weniger durch dich. :p

    Was lapperst du eigentlich hier zusammen? Was haben RISC-Compiler mit einer GUI zu tun?
    Es geht hier nicht um "Über den Tellerand", sondern um GUIs. Da sind Standard-Header nun wirklich absolute Haarspalterei bzgl. der Kompilatgröße.
    Wenn man sstream nicht braucht, muss man es auch nicht einbinden. Wenn man nicht alle IOStream-Komponenten braucht, kann man auch <iosfwd> nutzen. Ich sehe hier kein Problem.
    :xmas2:

    0
  • D

    Was lapperst du eigentlich hier zusammen? Was haben RISC-Compiler mit einer GUI zu tun?

    Was lapperst du eigentlich hier zusammen? Was hat eine GUI mit der Größe einer Binary zu tun?

    Schönen Advent
    G-DC!

    0
  • A

    Ich habe mit dieser sinnlosen Diskussion nicht angefangen.

    Nanyuki schrieb:

    Edit: wobei 800 KB natürlich auch schon recht viel sind.
    Es wäre sicher eine Überlegung wert, auf die Standard-Streamheader zu verzichten, die kosten immerhin rund 500 KB.

    Dir auch einen schönen Advent. :xmas1:

    0
  • B

    Artchi schrieb:

    Die Diskussion ist lächerlich. Zumal die C-Funktionen in keiner Weise mit dem C++-IOStreams vergleichbar sind. Man nutzt Features, wie Typsicherheit, Bufferoverflow-Sicherheit usw. und da kann man eine größere EXE in Kauf nehmen.

    Ich denke, es ist vor allem unerwartet. Typsicherheit verursacht keinen größeren Code und die paar if-Abfragen um Bufferoverflows zu verhindern, dürften keine hundert Kilobyte verursachen.
    Ich hätte auch eher vermutet, dass der Linker alles rauswirft, was nicht benötigt wird.

    0
  • L

    Schaut euch das mal an, mein Projekt hat es sogar schon auf die "softpedia.com" Webseite geschafft 😃

    Download Seite: http://www.softpedia.com/get/Programming/Other-Programming-Files/EasyWindow.shtml
    Award Seite: http://www.softpedia.com/progClean/EasyWindow-Clean-147133.html

    Riesig ^^

    0
  • L

    Neuigkeiten für das neue Jahr: :xmas1:

    Ich werde wahrscheinlich inerhalb nächster Woche eine neue Version (EasyWindow 1.1) auf soruceforge hochladen.

    Das ScrollAreaGadget habe ich auf jeden Fall neu implementiert, die ToolBar mit ihren Rebars wurde etwas verbessert, das ListIconGadget mit seinen Kategorien funktioniert auch schon deutlich besser und Images können jetzt auch selbst erstellt werden.
    So kann man z.B. eine Bild laden (das muss aber von einem anderen Programm gemacht werden, z.B. die SoftPixel Engine ^^) und dann als 'ColorBuffer' im RGBA Format an das Image übergeben werden.

    Dazu ist auch eine neue Klasse hinzuefügt worden: ewColorRGBA

    Und insgesammt wurden natürlich in einigen Klassen der Funktionsumfang erweitert.
    z.B. für das TreeGadget nicht nur AddItem sondern jetzt auch RemoveItem.

    Mfg Lukas

    PS: und ich hab' den Header sstream rausgenommen und mit sprintf für meien Zwecke gearbeitet. Jetzt ist die DLL nur noch 331 KB groß 😃

    0
  • L

    Hi,

    eben gerade habe ich die neue Version EasyWindow 1.1 auf sourceforge.net hochgeladen.

    http://sourceforge.net/projects/easywindow/files/

    Viel Spaß 🙂

    0
Anmelden zum Antworten