EasyWindow

Dummie

Ich stelle mir die Portierung von EasyWindow als ziemlich schwierig vor. Im Prinzip müsste man alles neu schreiben. Vielleicht solltest du versuchen, einige Dinge noch weiter zu kaspeln, so dass die Portierung später einfacher fällt.

Kóyaánasqatsi

Alter, ich sauge mit 100 B/s o0.

EDIT:
Ah, mit einem anderen Mirror gayts.

Mr. N

Wieso so viele Pointer?

blub* 0

Auch in diesem Projekt fallen doch parallelen zur Irrlicht Engine auf.
Zum Beispiel erstellen eines Objekts über eine globale Funktion.
Ich habe da irgendwie noch nicht verstanden warum man nicht einfach ein Objekt anlegen kann das die ganzen nötigen Initialisierungen im Konstruktor macht?!
Ansonsten: sieht vor allem schön einfach aus... wobei, noch eine Frage: wieso ...->CreateWindowClass("...") und nicht einfach ->CreateWindow("...")? Fände ich logischer und wäre auch noch kürzer ;).

LukasBanana

Weil mehrere Fenster eine Klasse nutzen können.

blub* 0

Wozu brauche ich denn die WinClass außerhalb vom Device?

DeepCopy

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.

Wie kann man so was feststellen? Ich meine wo und wie, also Ort und Größe? Welche Tools?

G-DC!

Nanyuki

DeepCopy schrieb:

Wie kann man so was feststellen? Ich meine wo und wie, also Ort und Größe? Welche Tools?

Außer dem gcc brauchst du dafür nicht viel...
Hello World mit printf: 6 KB
Hello World mit printf und std::string: 81 KB
Hello World mit cout: 522 KB

Spart also 441 KB.
Sofern man für Dateioperationen nicht die Standard-fstream-Klassen verwendet, kann man auf diese Header also getrost verzichten und stattdessen ein paar einfache Wrapper um printf bauen.

DeepCopy

Sieh mal einer an! Das dass so einen gewaltigen Code-Bloat verursacht hatte ich gar nicht realisiert.

Danke für die Info!

G-DC!

Dummie

Nanyuki schrieb:

DeepCopy schrieb:

Wie kann man so was feststellen? Ich meine wo und wie, also Ort und Größe? Welche Tools?

Außer dem gcc brauchst du dafür nicht viel...
Hello World mit printf: 6 KB
Hello World mit printf und std::string: 81 KB
Hello World mit cout: 522 KB

Spart also 441 KB.
Sofern man für Dateioperationen nicht die Standard-fstream-Klassen verwendet, kann man auf diese Header also getrost verzichten und stattdessen ein paar einfache Wrapper um printf bauen.

Hello World mit VC++ 2008 (Release-Modus):

#include <stdio.h>

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

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

	return 0;
}

=> 7 KB

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

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

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

	return 0;
}

=> 7,5 KB

#include <iostream>
#include <string>

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

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

	return 0;
}

=> 8 KB

Selbst im Debug-Modus kommt der obere Code, der nur C++ Funktionen nutzt auf 34,5 KB!

Ich finde deine Werte also sehr mysteriös und kann mir nicht vorstellen, dass es so gewaltige Unterschiede zwischen Windows und Linux gibt (hab auf Dateigrößen nie geachtet).

Im übrigen sollte sich C++ Code mit gcc imho gar nicht kompilieren lassen. Dazu benötigt man doch g++?

Blue-Tiger

Dummie schrieb:

Im übrigen sollte sich C++ Code mit gcc imho gar nicht kompilieren lassen. Dazu benötigt man doch g++?

GCC ist auch der Ueberbegriff fue die "Gnu Compiler Collection", nicht nur fuer den "Gnu C Compiler". Wenn er also gcc sagt, meint er den C++ Compiler vom gcc

Nanyuki

Visual C++ linkt sicherlich gegen die C++ Runtime Library, deswegen die kleine Größe.
g++ unter Linux linkt auch dynamisch, MinGW aber nicht. Keine Ahnung, ob MinGW und Microsoft-Runtime kompatibel sind. Falls es so sein sollte, wäre das natürlich praktisch.

DeepCopy

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!

Artchi

Und du willst uns jetzt genau was damit sagen?

Nanyuki

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.

Ad aCTa

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.

DeepCopy

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!

DeepCopy

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!

Maxi

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!

Artchi

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.