C++ ungeeignet für 64K Demos?

Hi,

mir fällt grade auf das schon 2 Header (<string> und <iostream>) dazu ausreichen im Releasemode die Binary auf 120 KByte zu puschen für NIX! Wieso bläht C++ die Programme so sinnlos auf?

c.rackwitz

liegt daran, dass du mit <string> alle funktionen und klassen da drin mit includest.
c++ sortiert da nichts aus.

bei 64k demos würd übrigens am liebsten assembly und/oder reines c genommen.
dieses ganze stl zeug bläht deine exen so auf.

Hmn ja, aber ich frage mich wieso das Programm dadurch so dermaßen aufgebläht wird? Wenn ich nur std::string benutzen will um ein klein wenig mit texten zu arbeiten wird mein Programm 50KB größer und das nur für eine kleine Klasse

Lohnt es sich da eine eigene std::basic_string zu schreiben? Ich find das irgendwie geschlampt von denen, das mein Programm so aufgebläht wird.

Blue-Tiger

string & iostream sind nicht sooo klein. Immerhin stecken hinter beiden Template-Klassen (hinter iostream ausserdem noch eine ganze Klassenhierarchie) und die sind ja bekannt dafuer, den Code aufzublaehen.

Blue-Tiger

string & iostream sind nicht sooo klein. Immerhin stecken hinter beiden Template-Klassen (hinter iostream ausserdem noch eine ganze Klassenhierarchie) und die sind ja bekannt dafuer, den Code aufzublaehen.

Auf Iostream wuerd ich deshalb verzichten. Und ein kleiner Wrapper um char* - Strings lohnt sich IMO schon.

volkard

bitte genauer trennen.

C++ ungeeignet für 64K Demos?

ganz im gegenteil. c++ ist ideal geeignet für 64k-demos.

mir fällt grade auf das schon 2 Header (<string> und <iostream>) dazu ausreichen im Releasemode die Binary auf 120 KByte zu puschen für NIX!

aber <string> und <iostream> sind absolut ungeeignet.

nach c ausweichen tun nur deppen machen. nach asm ausweichen ist bei wettbewerben immer eine überlegung wert.

rüdiger

C++ ist doch ideal für eine 64k Demo.

Dank Template Tricks kannst du doch sogar einiges rausholen. Die Standard Library ist eben nicht so gut geeignet. Aber wer Platz sparen will nimmt ja auch keine Standard C Library.

c.rackwitz

was denn für template tricks?
wo ist c++ da besser als c geeignet? (standard libs außen vor gelassen)

Hi,

also ist die STL anfürsich dafür total ungeeignet aber C++ selber nicht?

Wenn man jetzt mit strings arbeiten will, würde es sich da lohnen auf char-Arrays und C-Funktionen zurückzugreifen oder wäre es da besser eine eigene std::string zu coden? Das selbe für stringstreams.

Noch paar fragen zum Thema 64K-Demos:

inline ja/nein - warum?
const-correctnes ja/nein - warum?
eigene STL coden (z.B. std::string) ja/nein - warum?
viele klassen ja/nein - warum?

und wie sehen diese template-tricks aus?

volkard

***************** schrieb:

Hi,
also ist die STL anfürsich dafür total ungeeignet aber C++ selber nicht?

so ist es.
naja, die stl mit einigen sachen auch prima gut. aber <string> und <iostream> haben in einer 64k-demo absolut nix zu suchen.

Wenn man jetzt mit strings arbeiten will, würde es sich da lohnen auf char-Arrays und C-Funktionen zurückzugreifen oder wäre es da besser eine eigene std::string zu coden?

das eine schließt das andere nicht aus. man schreibt sich wenigstens erstmal nen wrapper um char*, damit man vergleichsoperatoren statt strcpy hat. überlegenswer ist, ob man begin/end speichert, oder immer strlen-aufrufe haben mag. hängt von der demo ab, was man mit den strings macht.

Das selbe für stringstreams.

stringstreams könnten konzeptionell zu teuer sein. vielleicht lieber sprintf nehmen oder strcat oder nee, eigene funktionen, ja, das rult.

inline ja/nein - warum?

bei großen funktionen nicht. wenn die funktion 200 bytes kostet aber ein aufruf nur 10 bytes, dann ruft man natürlich auf (außer, die funktion wird sicher nur ein einziges mal gebraucht). bei sehr kleinen funktionen muss aber inline sein. da ist dann das reinkopieren des funktionscodes billiger als ein aufruf. und inline-ersetzung findet ja vor dem, optimieren statt. deswegen kann's auch oft vorkommen, daß man eine inline-funktion als mit 0 bytes zu buche schlagend feststellen darf.

const-correctnes ja/nein - warum?

nur, wenn du voll-profi bist. ich denke da an die beiden op[] und an die automatische umwandlung nach const&.

eigene STL coden (z.B. std::string) ja/nein - warum?

eigene coden. stl ist dafür da, alle anwendungen einigermaßen schnell zu unterstützen. du braucht dich nur um eine anwendung zu kümmern, brauchst keine kompromisse, also kannste sehr statt einigermaßen. und du willst klein und nicht schnell.

viele klassen ja/nein - warum?

extrem viele. viele viele viele. wie immer in c++ halt.
wenn die demo dann fertig ist, aber du noch 3 tage zwit hast, was machste dann? klaro. mal testen, ob deine klasse String auch gut mit copy-on-write wäre. mal testen, ob deine ausgabefiles mit memory mapping kleiner wären als mit write (und leider manchmal buffer-kopierungen). mal testen, mal testen. und immer nur, indem eine einzige klasse verändert wird und bei gutem design brauchste am rest des ganzen projekts nix ändern. deswegen (und wegen einfachheit) muss für jeden zweck eine klase her.

und wie sehen diese template-tricks aus?

schattig. du mußt halt genau wissen, was du machst (auch immer wieder den erzeugten asm-code angucken, um ein gefühl dafür zu kriegen, was der compiler draus macht).

am schliss haste gegen den c-programmierern keinen nachteil, aber einen klaren vorteil. dein code ist einfacher und manche optimierungen kann man erst in einfachem code sehen.

@Volkard
Vielen dank! Hast du sonst noch paar Tips?

c.rackwitz schrieb:

was denn für template tricks?

Die Antwort werden sie uns schuldig bleiben.

the_alien

Ist zwar ne 96K Demo, aber egal:

- .kkrieger is not written in 100% assembler/machine language. Not even nearly. Like the
vast majority of game projects being developed today, .kkrieger was mostly written in
C++, with some tiny bits of assembler where it is actually advantageous (notably, there
are a lot of MMX optimisations in the texture generator).

.kkrieger war glaube ich der Gewinner der letztjährigen Breakpoint in der Kategorie 96K. Aber nicht drauf festnageln bitte

the_alien schrieb:

Aber er hat doch Recht diesmal.

Würde ich nicht sagen, wenn er eine 64KByte demo macht mit vielen Texteffekten, wäre ne std::string schon praktisch!

volkard

..................... schrieb:

@Volkard
Vielen dank! Hast du sonst noch paar Tips?

nichts, was ich in ein paar sätzen aufschreiben könnte, füchte ich. und nix allgemeines.
aber vielleicht stellste einfach konkrete fragen, wenn du was vor hast, und dich fragst, wie man das am besten klein kriegt.

doch noch was allgemeines. kein rtti. keine exceptions (eher keine fehlerbehandlung!). globalen op new überladen (gibt ja in der WinApi feinen ersatz). compileroptionen kennen. ich nehme an, exe-packer ind erlaubt? dann so einen auch nehmen.
aber bei 64k hat man so unheimlich viel platz für code, daß es gar nicht mehr am code liegt, sondern an den gafiken und models (generatoren nehmen, wenn möglich statt gepackter bitmaps ist wohl zur zeit in. ka, bin nicht in dieser szene daheim.).

Gut dann hab ich jetzt paar fragen:

- Wie sähe so ein überladener new-operator aus? Wieso sollte man den überhaupt überladen?

- Sollte man viel mit new arbeiten oder lieber statische-arrays schreiben? also char buffer[32];?

- Warum keine Exceptions?

- wie fängt man am beste für eine eigene string-klasse an? welche features sollten umbedingt rein und welche nicht?

audacia

..................... schrieb:

- Sollte man viel mit new arbeiten oder lieber statische-arrays schreiben? also char buffer[32];?

Statische Variablen sind schneller erstellt; derart kleine Arrays verursachen auch bestimmt keinen Stacküberlauf.

..................... schrieb:

- Warum keine Exceptions?

Weil die Überprüfung auf Exceptions deinen Code aufbläht.

audacia schrieb:

..................... schrieb:

- Sollte man viel mit new arbeiten oder lieber statische-arrays schreiben? also char buffer[32];?

Statische Variablen sind schneller erstellt; derart kleine Arrays verursachen auch bestimmt keinen Stacküberlauf.

Und wie ist das mit der größe?

Also ich glaube es gibt sicherlich einen unterschied in der größe der datei wenn ich:

char buffer[2048]; schreibe als

char *buffer = new char[2048];

volkard

..................... schrieb:

- Wie sähe so ein überladener new-operator aus?

void* operator new(size_t size){
   return HeapAlloc(GetProcessHeap(),0,size);
}
void operator delete(void* p){
   HeapFree(GetProcessHeap(),0,p);
}

Wieso sollte man den überhaupt überladen?

weil bei windows ein kleines speichermanagement eingebaut ist. es ist langsam und so, kein vergleich zum mitgelieferten operator new. aber es ist extrem wenig code für's eigene programm.

- Sollte man viel mit new arbeiten oder lieber statische-arrays schreiben? also char buffer[32];?

statische arrays sind noch billiger. zum freigeben braucht man gar keinen code und zum anlegen muß nur der stackpointer inkrementiert werden. außerdem werden statische arrays viel schneller angelegt.
aber was ist, wenn man die größe nicht zur compilezeit kennt oder wenn man innerhalb einer funktion speicher anlegen möchte und den speicher zurückgebenb will? da muß schon new her.

- Warum keine Exceptions?

das exception-handling macht beim MinGW schon allein 20k aus. das kann sich natürlich keiner leisten. ok, mal alternativen angucken.
a) kleineres exception-handlich schreiben.
ist sehr schwirig, weil a viel compilermagie dabei ist
b) das in den microsoft-dlls benutzen
keine ahnung, ob das erlaubt ist. ich vermute mal: nein.
c) fehler wie gewohnt in c hochgeben.
naja, bei mini-programmen ist das billiger als exception-handling. bei fetteren programmen wird dann das exception-handling billiger.
d) einfach alle fehler ignorieren!
yeah, that's it! wenn der user keine soundkarte hat oder directx nicht hat, kackt das prog einfach ab. das scheint mir ideal für 64k-demos.

- wie fängt man am beste für eine eigene string-klasse an?

so:

class String{
   char* date;
public:
   String(char const* d=""){
      data=new char[strlen(d)+1];
      strcpy(d,data);
   }
}

welche features sollten umbedingt rein und welche nicht?

je nach dem, was die anwendung machen soll. strings könnten zum beispiel welche sein, die keinen besitz am speicher haben

class String{
   char const* date;
public:
   String(char const* d=""){
      data=d;
   }
   friend bool operator==(string const a,string const b){
      return strcmp(a.data,b.data)==0;
   }
}

und die nur dafür sorgen, daß man mit char* ein wenig leichter umgehen kann und einen eigenen namen hat. das wäre zunächst mein weg, denn ich fürchte, außer ein paar dateinamen und so würden strings nicht viel verwendet werden. und wieder der vorteil, ich kann auch ganz am ende, wenn ich feststelle, daß ich doch andere strings hätte nehmen sollen, sie an einer zentralken stelle (der String.cp) verändern und das ganze programm hat was davon.

sie könnten auch wie die klasse zuvor sich immer eine kopie der daten machen und dann konsequenterweise im destruktor die kopie löschen. sie könnten auch in einer globalen hashtable ihre daten eintragen und nur indizes auf die hashtable führen.

@volkard
Vielen Dank! Doch noch eine frage zur string-klasse: Du initialisierst mit new, aber gibst den speicher nicht mehr frei? Also das du von Fehlerbehandlung in 64K-Demos nichts hälst hast du ja erklärt aber Fehlermachung? :D:D:D