Spieleprogrammierung: C vs C++ - SDL vs SFML

Hey Leute,

ich bins mal wieder.
Und zwar stelle ich mir derzeit die Frage, was besser wäre, wenn man einfache/normale 2D und später vielleicht einmal so ein 2,5D/3D-Spiel programmieren will.
(Duke Nukem 3D ist beispielsweise ein 2,5D-Spiel, kein vollwertiges 3D)
C oder C++?

Ich weiß, die heutigen Engines sind zumeist in C++ programmiert,
doch dann denk ich mir, dass C am schluss doch Ressourcenschonender wäre (z.B. Duke Nukem 3D - in C programmiert und benötigt nur 8MB RAM, auch wenns eine schlechte Grafik hat ist das Spiel trotzdem klasse).
Abgesehen davon, dass ich mehrere Leute aus meiner Arbeit gefragt habe, was sie lieber mögen: C oder C++
wobei alle auf C gegangen sind, da sie C++ als eine "nicht schöne" Sprache sehen oder sie designtechnisch paar sachen nicht leiden können (z.B. Mehrfachvererbung).

Und wenn es um den Punkt geht, dass man Spiele viel besser mit einer objektorientierten Sprache programmieren kann, dann kann ich genauso sagen, dass man früher die Spiele auch 'nur' in C programmiert hat, abgesehen davon dass es ja GObjects gibt, um in C dann objektorientiert zu programmieren.


Und genauso ist es mit den zwei Librarys:
Bei SDL denke ich mir, dass es vielleicht eben wieder Ressourcenschonender sein wird, wobei dann SFML wieder mit mehr Librarys sowie Objektorientierung punktet.
Dann hab ich mich selber etwas informiert, so wurden z.B. Angry Birds mit SDL programmiert, da das auch auf Android lauffähig ist (was SFML noch nicht ist) - da würde man eigentlich sagen: SDL nur für Spiele, die sehr portabel sein müssen.
Dann hab ich aber gesehn, dass Dota 2 auch mit SDL programmiert wurde -> ein Spiel, das es 'nur' unter den üblichen Desktop-Betriebssystemen gibt, wo man keine besondere Portabilität braucht. (Da frage ich mich auch, warum Dota 2 nicht mit SFML programmiert wurde,..?)
Bei SFML denke ich mir hald wieder, dass es heißt, es wäre moderner (keine Ahnung, ob das stimmt) und dass es einem auch leichter fällt mit SFML Spiele zu programmieren, da es einem Arbeit abnimmt.

Leute, helft mir bitte. ^^
Eine kleine Diskussion wäre nicht schlecht, Danke

LastChosenOne schrieb:

Ich weiß, die heutigen Engines sind zumeist in C++ programmiert,
doch dann denk ich mir, dass C am schluss doch Ressourcenschonender wäre (z.B. Duke Nukem 3D - in C programmiert und benötigt nur 8MB RAM, auch wenns eine schlechte Grafik hat ist das Spiel trotzdem klasse).

Zum Vergrößern anklicken....

Mir fällt absolut kein Grund ein, weshalb C in irgend einer Weise ressourcenschonender als C++ sein sollte.

LastChosenOne schrieb:

Abgesehen davon, dass ich mehrere Leute aus meiner Arbeit gefragt habe, was sie lieber mögen: C oder C++
wobei alle auf C gegangen sind, da sie C++ als eine "nicht schöne" Sprache sehen oder sie designtechnisch paar sachen nicht leiden können (z.B. Mehrfachvererbung).

Zum Vergrößern anklicken....

Seltsamer Grund. Mehrfachvererbung ist eine Option, die die Sprache hergibt, die aber in der Praxis fast nie oder zumindest sehr selten verwendet wird. Es ist ja nicht so, daß dich irgend wer zwingt, Mehrfachvererbung anzuwenden, bloß weil du in C++ programmierst.

Jetzt sag ich dir aber mal eine der meines Erachtens hilfreichsten Programmierstrategien, und zwar eine die C++ kann und C nicht: RAII (im Zweifelsfall googlen).
Dann wären da noch die wesentliche bessere Typsicherheit in C++. Und die Unterstützung für generische Programmierung (Templates).

Wenn du objektorientiert programmieren willst, kannst du das mit jeder Sprache tun, die Support für Abstraktion von zusammengesetzten Daten hat. Deshalb ist dieser Punkt unwichtig, was die Entscheidung zwischen C und C++ angeht.

Ich rate dringend von beiden Programmiersprachen ab. In C bist du zu viel damit beschäftigt, Sachen zu tun, um das Erreichen deines Ziels einfacher zu machen, ohne auch nur einen Schritt näher dran zu kommen.
C++ erbt alle Schwächen von C und türmt darauf Komplexität und allgemein idiotische Ideen und weiß am Ende nicht, was es eigentlich selbst sein will.

Nimm eine moderne Programmiersprache, die dir die Arbeit abnimmt, deine eigenen Werkzeuge bauen zu müssen. Welche es wird, lasse ich offen, denn ich will dich nicht versehentlich zu meiner Religion bekehren. Auswahl gibt es genug.

€: Ich muss mir für folgendes noch einen Copy/Paste-Textbaustein zurechtlegen:

Fragen wie nehme ich dies oder nehme ich das führt in diesem Forum zu keinem Erkenntnisgewinn, sondern zu ausufernden Religionskriegen, in denen niemand Recht hat, aber alle von ihrem Standpunkt fest überzeugt sind. Ich wünsche dir, dass dieser Thread eine rühmliche Ausnahme bleibt, aber habe da wenig Hoffnung.

asdfman schrieb:

Wenn du objektorientiert programmieren willst, kannst du das mit jeder Sprache tun, die Support für Abstraktion von zusammengesetzten Daten hat. Deshalb ist dieser Punkt unwichtig, was die Entscheidung zwischen C und C++ angeht.

Ich rate dringend von beiden Programmiersprachen ab. In C bist du zu viel damit beschäftigt, Sachen zu tun, um das Erreichen deines Ziels einfacher zu machen, ohne auch nur einen Schritt näher dran zu kommen.
C++ erbt alle Schwächen von C und türmt darauf Komplexität und allgemein idiotische Ideen und weiß am Ende nicht, was es eigentlich selbst sein will.

Nimm eine moderne Programmiersprache, die dir die Arbeit abnimmt, deine eigenen Werkzeuge bauen zu müssen. Welche es wird, lasse ich offen, denn ich will dich nicht versehentlich zu meiner Religion bekehren. Auswahl gibt es genug.

Zum Vergrößern anklicken....

100% AGREE!!!

Also um eine Entscheidung zu treffen fände ich Informationen über dich selbst wichtig. Was kannst du? Warum willst du dich unbedingt für eine von diesen beiden Sprachen entscheiden? Nur wegen SDL und SFML? Klar wurden viele Spiele früher in C/++ entwickelt aber heute gibt es so viele andere Möglichkeiten. Hier zwei Beispiele:

XNA wurde zwar von Microsoft begraben, was aber keinen daran hindern kann es weiter zu benutzen. Hier würdest du in C# entwickeln (IMO eine der bequemsten Sprachen), das würde dir den Einstieg extrem erleichtern (falls du Einsteiger bist). Außerdem ist XNA sehr intuitiv und schnell zu erlernen!

JOGL Spiele würdest du in Java entwickeln (auch sehr bequem!). Dabei würdest du alle wichtigen Konzepte der OpenGL-Programmierung erlernen ohne das (imo) müßige C++ lernen zu müssen. Später könntest du diese dann aber auch in einer C++ Applikation anwenden (z.B. mit SDL).

Vielleicht würde ich noch Flash nehmen aber das kenne ich nicht so gut.

Also insgesamt würde dir eines dieser Frameworks/Spezifikationen den Einstieg sehr erleichtern und extrem viel Zeit sparen. Falls du doch auf C oder C++ bestehst kann ich dir eins sagen...ES IST ABSOLUT EGAL!!! Nimm irgendeine Sprache die dir Spaß macht, eine in der du dich gut zurecht findest und fang an zu programmieren! Alles andere wird sich von selbst ergeben!

Gruß,
dein Käsebrot


P.S.: Du als "ein Mann Armee" wirst wohl kaum etwas soooo ressourcenlastiges entwickeln, dass du dich zwischen C und C++ entscheiden musst

IKäsebrot schrieb:

Falls du doch auf C oder C++ bestehst kann ich dir eins sagen...ES IST ABSOLUT EGAL!!!

Zum Vergrößern anklicken....

Diese Meinung höre ich oft, obwohl ich sie absolut nicht nachvollziehen kann. Wieso sollte es auch nur im Ansatz egal sein, ob du die mächtigere, bequemere Sprache oder das wesentlich schmalere C wählst?? Klar ist C weniger komplex; dafür bietet es dir aber auch viel weniger.

antred schrieb:

Diese Meinung höre ich oft, obwohl ich sie absolut nicht nachvollziehen kann. Wieso sollte es auch nur im Ansatz egal sein, ob du die mächtigere, bequemere Sprache oder das wesentlich schmalere C wählst?? Klar ist C weniger komplex; dafür bietet es dir aber auch viel weniger.

Zum Vergrößern anklicken....

Natürlich hast du Recht jede Sprache hat ihre Vor und Nachteile und es ist keineswegs völlig egal was in welcher Sprache entwickelt wird...aber:

Wenn du dir diverse Foren (nicht nur hier) anguckst wirst du folgendes schnell feststellen. Vor allem wenn es um Spieleentwicklung geht, tauchen mindestens 2-3x die Woche neue Benutzer auf, die World of Warcraft programmieren wollen, keinerlei Vor bzw. Grundkenntnisse haben und sich alleine darüber den Kopf zerbrechen welche Sprache oder welches Framework sie nehmen sollen. Ich hoffe du verstehst worauf ich hinaus will. Wenn du sowas liest wie "ES IST ABSOLUT EGAL!!!" soll das eigentlich nur bedeuten:

Hör auf Luftschlösser zu bauen und fang an zu coden, der Rest kommt mit der Zeit!
(und ein schneller Einstieg ist mit modernen Hochsprachen eben viel bequemer, imo!)

Schau dir mal http://www.rust-lang.org/ an.
Obwohl die Sprache noch sehr jung ist, hat sie in der game-development Szene schon einiges an Fahrt aufgenommen und könnte das "next big thing" werden.

noobzkillor schrieb:

Schau dir mal http://www.rust-lang.org/ an.

Zum Vergrößern anklicken....

Hmm, das hört sich tatsächlich recht interessant an! https://en.wikipedia.org/wiki/Rust_(programming_language)

LastChosenOne schrieb:

Und zwar stelle ich mir derzeit die Frage, was besser wäre, wenn man einfache/normale 2D und später vielleicht einmal so ein 2,5D/3D-Spiel programmieren will.
(Duke Nukem 3D ist beispielsweise ein 2,5D-Spiel, kein vollwertiges 3D)
C oder C++?

Zum Vergrößern anklicken....

Wenn es dir darum geht ein Spiel zu programmieren würde ich einfach mal Unity3D + C# in den Raum werfen.

Warum?
Du willst ja ein Spiel programmieren und keine Hardcore Spiele Engine schreiben oder? Und mit Unity3D oder von mir aus auch einer anderen fertigen Engine in C++/C# lässt sich das wesentlich schneller erreichen als wenn du bei quasi 0 anfängst und dir deine Engine erst mal selber basteln musst.

Wenn du ein Programm entwickeln willst nimmst doch als Unterbau auch ein fertiges Betriebssystem und fängst nicht an dir ein eigenes zu bauen

So nebenbei:
Ich programmier in der Arbeit C# und weiß, dass es recht bequem ist, aber ich möchte mein Spiel selber gern in C / C++ programmieren.
Und ich hab wohl vergessen zu erwähnen, dass ich C bzw. C++ schon kann, wobei ich C++ etwas mehr kann als C.

Ich werde mein Spiel auch nicht in Java programmieren, auch wenn ich eine "Ein-Mann-Armee" bin und das Spiel eh nicht soo groß werden wird.

Genauso möchte ich auch nicht eine vorgefertigte Engine verwenden, ich kenne die Unity-Engine aber möchte mir selber etwas zusammen basteln.

Und warum ich denke, dass C wesentlich ressourcenschonender gegenüber C++ ist?
Weil es eine Tatsache ist! Die C-Programme sind für Gewöhnlich immer kleiner als C++ Programme und der RAM-Verbrauch ist auch fast immer geringer (da in C++ z.B. für die einzelnen Objekte wieder Pointer gebraucht werden, dann für die VTables, etc.)

Ich möchte so weit gern eure Meinung zu wissen, was von den oben von mir vorgestellen ihr nehmen würdet.
Und bitte keine neuen Vorschläge mit anderer Programmiersprache oder einer fertigen Engine, auch wenns nett gemeint ist. ^^

LastChosenOne schrieb:

Und warum ich denke, dass C wesentlich ressourcenschonender gegenüber C++ ist?
Weil es eine Tatsache ist! Die C-Programme sind für Gewöhnlich immer kleiner als C++ Programme und der RAM-Verbrauch ist auch fast immer geringer

Zum Vergrößern anklicken....

Das hängt ganz allein davon ab, wer die Programme erstellt hat. Da hatte der jeweilge C-Programmierer dann wohl einfach mehr auf dem Kasten als sein C++-Pendant.

EDIT: Die meisten iostream-Implementierungen sind leider suboptimal und deutlicher weniger performant als printf() & co, aber das liegt an in diesem Punkt etwas mangelhaften Implementierungen der C++-Standard-Bibliothek und nicht an der Sprache C++ selbst. Wie Scott Meyers in einem seiner Bücher (Titel ist mir entfallen) schrieb, rein theoretisch könnte eine gut geschriebene iostream-Implementierung printf() sogar schlagen, da hier die Typen zur Kompilierzeit schon bekannt sind und nicht erst ein Format-String geparst werden muß.

LastChosenOne schrieb:

(da in C++ z.B. für die einzelnen Objekte wieder Pointer gebraucht werden, dann für die VTables, etc.)

Zum Vergrößern anklicken....

Den ersten Teil verstehe ich jetzt mal gar nicht. Solltest du vielleicht etwas klarer ausführen. Vtables gibt es nur dann, wenn du Klassen mit virtuellen Funktionen verwendest. Würdest du dir etwas funktional äquivalentes in C selber zusammenbasteln, brächte das vergleichbaren (und höchstwahrscheinlich sogar größeren) Overhead mit sich.

Kurzform: Ich würde einfach sagen man verwendet C++ weil es der aktuell beste Kompromiss ist. Man kann darin genau so modern/elegant wie in Java/C# programmieren und verliert trotzdem keine Performance oder Plattformkompatibilität.

Wenn du schon programmieren kannst verstehe ich nicht so richtig, wieso du hier fragst. Alle großen Spiele sind in C++ programmiert.. das wird seinen Grund haben. Genau so wie ihr auf der Arbeit wahrscheinlich Windows Applikationen entwickelt und daher C# verwendet. Da würde ich erstmal der Masse der Spieleentwickler-Experten trauen die sich für C++ entschieden haben und es nachmachen.

Zusätzlich: C++ kann nicht ressourcen-verschwendender sein als C, da man alle "Schweinereien" anstellen kann die C programmieren machen, weil sie denken ihren Quellcode dadurch zu beschleunigen, was mit Compilern aus diesem Jahrtausend eh nicht mehr stimmt.

Siehe auch hier1, hier2, hier3, hier4
Warum ich embedded verlinke, obwohl es um Spiele geht? Dort sind die Anforderungen an Echtzeitfähigkeit deutlich höher und Ressourcen wie Speicherplatz und CPU Durchsatz begrenzter. Außerdem ist der Quellcode meist kleiner. Dh dass es dort sogar noch einfacher wäre hoch-optimiertes C zu schreiben. (Natürlich sind winzigste 4/8 bit µC eine Ausnahme wo man nicht "viele kb" Speicher zur Verfügung hat und es darum geht das Binary minimal zu kriegen aber nicht darum maximale FPS zu erreichen.)

Wirkliche Optimierung erreicht man, indem man zB Korrelation nicht stumpf durch eine Doppelsumme berechnet sondern durch DFT. Also indem man hochoptimierte Bibliotheken verwendet, die Probleme zigmal besser gelöst haben als man es selbst könnte.

Oder indem man sich im Mikro-Optimierungs-Bereich um sowas kümmert: Branch-Prediction, Cache-Lokalität. Beim zweiten ist vor allem die 2te Antwort mit der 8 mal schnelleren rekursiven Lösung interessant. Weitere Beispiele

Außerdem sind moderne Compiler explizit darauf hin optimiert STL Code zu optimieren. Dh kein C/C++ "Anfänger" hat auch nur ansatzweise die Chance Algorithmen effizienter in C/C++ zu schreiben, als die STL oder Libs wie OpenCV sie schon zur Verfügung stellt. Dh für alles was ernsthaft Rechenzeit kostet wirst du oft eh fertige Lösungen verwenden und nicht selbst C Code optimieren.

Außerdem darfst du die doofe Realität nie vergessen: Kein einziges wirtschaftliches Programm wird bis ans Limit optimiert.
Dh wenn zB die Durchführung eines Projekts (inkl Bugfixing bis zum Kundentauglichen Release) in C 30 Mannjahre brauchst und in C++ nur 20 dann hast du in C++ eben auch mehr Zeit übrig um dir um Optimierung Gedanken zu machen. Dieser Aspekt wird bei dieser oft geführten Diskussion fast immer vergessen... und ich denke 3:2 ist hier durchaus eine realistische Schätzung. Selbst wenn ein einzelner C Guru für ein kleines Projekt hier natürlich den Gegenbeweis antreten könnte, wird sich dieses Verhältnis bewahrheiten, wenn man von einem Projekt mit vielen Entwicklern redet wo das Personal während der Durchführung auch wechselt. Der Einstieg in ein fremdes aber ordentliches C++ Programm ist einfach leichter als in C.

LastChosenOne schrieb:

Und ich hab wohl vergessen zu erwähnen, dass ich C bzw. C++ schon kann, wobei ich C++ etwas mehr kann als C.

Zum Vergrößern anklicken....

Damit hast du dir deine Frage selbst beantwortet.

@antred: man kann in C beispielsweise statt einer VTable ein struct mit Funktionspoinitern erstellen, was dann etwas vergleichbares wäre, aber dennoch (wenn überhaupt) fast keinen Overhead mit sich bringt.
Oder hab ich selber hier gerade einen Denkfehler drin? ^^

@kuddlmuddl: Danke schon mal für die Links, ich werd alles morgen genauer durchlesen.
Und C++ wird auch 'hauptsächlich' wegen der OO, der schnelleren Codeentwicklung gegenüber C und der Tatsache, dass DirextX ebenfalls in C++ programmiert wurde, verwendet. Das muss nicht unbedingt heißen, dass es auch die bessere Wahl wäre. (wollt ich nur anmerken)
Deine Punkte finde ich selber recht interessant, und auch hast du recht, dass in wirtschaftlicher Hinsicht es besser ist, ein vergleichbares Programm lieber innerhalb von 20 Jahren (wie im Beispiel) statt innerhalb von erst 30 Jahren fertig zu stellen. Auch dass man danach noch Zeit hat, um sich Optimierungen zu überlegen, das hatte ich gar nicht bedacht.

Jetzt muss ich aber auch sagen, dass, nur weil eine Programmiersprache ein *zwischendrin* ist (zwischen OOP und Prozeduraler Programmierung) und es sonst keine alternativen damals gab bzw. immer noch nicht gibt (Performance-Technisch gesehen), heißt es nicht, dass es die bessere Wahl ist.
Und man sieht ja recht schön an Linux sowie den ganzen Distributionen, was man mit C alles anstellen kann - und wie "viel" Ressourcen es braucht (Debian mit GUI - 128 MB RAM, ist heutzutage nichts,..).
Und dann sieht man eben sowas wie Windows, wo so gut wie alles (außer der Kernel) in C++ programmiert wurde. (Win7: 1GB RAM dass es überhaupt läuft, und dann nicht einmal gut)
Klar kann mans jetzt auch auf die Programmierer bzw. Unternehmen schieben, dass Windows vielleicht nicht so effizient programmiert ist etc. - aber es war von mir selber soweit hald ein Anhaltspunkt.


BTW:
Von der API/Library her, was wäre dann besser?
Es heißt, dass SFML (C++) leichter und moderner wäre (durch OO), dann sieht man aber wiederum, dass recht schöne Spiele (wie oben genannt eben Dota 2 usw.) mit SDL (C) programmiert wurden.
(Es gibt auch 'Benchmarks' zwischen SDL und SFML, wobei SFML schneller wäre, aber auch nur, da in SDL bei den Benchmarks Software-Rendering aktiviert war, und nicht Hardware-Rendering über OpenGL).

man kann in C beispielsweise statt einer VTable ein struct mit Funktionspoinitern erstellen, was dann etwas vergleichbares wäre, aber dennoch (wenn überhaupt) fast keinen Overhead mit sich bringt.

Zum Vergrößern anklicken....

Es hindert dich niemand daran das selbe in C++ zu machen?
Aber dort gibt es mitlerweile viel bessere sachen: std::function std::bind wobei ich damit noch nie gearbeitet habe.
Außerdem sind structs nicht effizienter als eine class. Wenn man public/private anpasst entsteht sogar der selbe Assemblercode: Diskussion, Performance
Dieser vermutete "C++ Overhead" ist in der Realität einfach nicht (mehr) existent.
Ein sehr gutes Beispiel sind auch Exceptions: Jeder würde denken sie sind ein komplexes Sprachfeature, was nur ausbremst aber in echt sind sie beliebig viel schneller als C return-codes und nur durch das ++ möglich.

@kuddlmuddl: [...]

Zum Vergrößern anklicken....

Immer gerne. Du hast ja selbst auch noch viele passende Real-Welt Gründe ergänzt zu meinem doofen BWLer Argument Existierende Bibliotheken sind natürlich ein perfektes Beispiel. Niemand würde auf die Idee kommen eine ähnlich umfangreiche C++ Bibliothek nachzubauen nur um für sein Projekt C wählen zu können. Allerdings sind C Bibliotheken in C++ sehr wohl möglich.
Dh ich vermute auch mal stark, dass viele Projekte die zB SDL verwenden in C++ geschrieben sind.

Und man sieht ja recht schön an Linux [...]

Zum Vergrößern anklicken....

Der Vergleich hinkt sehr stark. Zum einen ist (oder nur war?) Windows auch viel mehr in C als C++ geschrieben - und zum anderen vergleichst du hier ein vollständiges Multimedia-OS mit einem sehr eingeschränkten. Ubuntu&Unity macht mit 128MB auch keinen Spaß.
Es gibt außerdem sehr wohl den Windows 8.1 Kernel für 64MB Systeme: WEB8 Industry. Das ist dann sogar Hart-Echtzeitfähig und kann in viel stärker Ressourcen-Beschränkten Systemen eingesetzt werden als einem x86 Desktop PC.
Mein aktueller 168Mhz µC ohne CPU-Cache hat gerade mal 196kB RAM und 1MB Flash und C++11 mit STL funktioniert wunderbar.. das allein ist also wirklich kein Argument.

Ganz generell noch hier eine qualifizierte Diskussion zum Thread-Thema: C++ for Game Programming - Love or Distrust?

LastChosenOne schrieb:

@antred: man kann in C beispielsweise statt einer VTable ein struct mit Funktionspoinitern erstellen, was dann etwas vergleichbares wäre, aber dennoch (wenn überhaupt) fast keinen Overhead mit sich bringt.

Zum Vergrößern anklicken....

Ja genau, dann hat jedes struct einen Pointer auf eine für seinen "Typ" passende Funktions-Pointer-Tabellen-struct-Instanz (was für ein Wort). Und jetzt gehe bitte noch mal in dich und denke drüber nach, was eine VTable ist und was ein VTable-Pointer ist.

Schau dir mal das http://www.3dgamestudio.com/ an, das ist Lite-C mit genug Lib's um direkt loszulegen.
Wird leider nicht mehr Weiterentwickelt aber um ein "kleines" Windows-Game zu schreiben reicht es noch lange.

@Kuddlmuddl: Zu Exceptions in C++, hab ich heut mal ausprobiert - ein kleines einfach Programm mit und eins Ohne Exceptions - sind 1:1 identisch, nur dass bei dem einen ein try-catch-block ist und bei dem anderen nicht. Das Ergebnis war, dass das Programm ohne Exceptions bei einer Größe von 10,5 KB über 1KB größer war, als das Programm ohne Exceptions. (Kompiliert mit GCC: gcc Test.cpp -o Test -s)
Dann hab ich bei dem Programm mit Exceptions ein weiteres mal 'throw string("Error");' geschrieben - und es wurde erneut um fast 1KB größer. Naja, Exceptions und schnell? Kann sein,... aber Exceptions und kleine Datei? anscheinend nicht so wirklich,.. Ein Overhead ist definitiv da, in Form einer größeren Datei (Binary) am schluss.

Von dem Embedded-Windows halte ich persönlich nicht allzu viel von. Da würd ich lieber auf ein Mini-Unix/Linux-System setzen,..


@IndianaX: Wie oben beschrieben möchte ich meine eigene kleine Engine zusammenbasteln, und das in C/C++. Trotzdem Danke.

LastChosenOne schrieb:

@Kuddlmuddl: Zu Exceptions in C++, hab ich heut mal ausprobiert - ein kleines einfach Programm mit und eins Ohne Exceptions - sind 1:1 identisch, nur dass bei dem einen ein try-catch-block ist und bei dem anderen nicht. Das Ergebnis war, dass das Programm ohne Exceptions bei einer Größe von 10,5 KB über 1KB größer war, als das Programm ohne Exceptions. (Kompiliert mit GCC: gcc Test.cpp -o Test -s)
Dann hab ich bei dem Programm mit Exceptions ein weiteres mal 'throw string("Error");' geschrieben - und es wurde erneut um fast 1KB größer. Naja, Exceptions und schnell? Kann sein,... aber Exceptions und kleine Datei? anscheinend nicht so wirklich,.. Ein Overhead ist definitiv da, in Form einer größeren Datei (Binary) am schluss.

Zum Vergrößern anklicken....

Die Philosophie von C++ war schon immer "you don't pay for what you don't use". Zusätzlicher Overhead entsteht also nur, wenn du diverse Features, die mit Overhead verbunden sind, in deinem Programm auch nutzt. Wenn dir ein paar Extra-kB in der Executable zu viel sind, dann nutze halt keine Exceptions. Überleg dir aber vorher noch mal, wie schwer ein paar kB in einem Programm, das auch tatsächlich was nützliches tut (und damit vermutlich eh wesentlich größer als 10 kB sein wird), ins Gewicht fallen.

aber Exceptions und kleine Datei? anscheinend nicht so wirklich,.. Ein Overhead ist definitiv da, in Form einer größeren Datei (Binary) am schluss.

Zum Vergrößern anklicken....

Da verstehe ich jetzt dein Argument nicht: Du sagst wegen 10kb Platzbedarf auf einem Desktop-Rechner bevorzugst du stattdessen die langsame Variante (Returncodes)? Und das in einer Diskussion wo es darum geht die schnellere Sprache zu wählen? Man könnte also sagen Exceptions sind ein trade zwischen time und space.. und bei Desktop SW würde man sich wegen 10kb sicherlich immer für weniger Rechenzeit entscheiden.
Selbst wenn: Exceptions sind keine Pflicht in C++ und Returncodes sind auch erlaubt. Außerdem hast du weder -O3 oder -OS verwendet. In Bereichen wo 10kb wichtig sind macht man das natürlich ohne Exceptions aber dann spricht trotzdem nichts gegen C++: Verkleinerung der Binary um Faktor 30

Außerdem vergleichst du Äpfel mit Birnen: Deine throw string("Error"); bläst das Binary natürlich auf. Aber hast du in der Variante ohne Exceptions auch eine string struct/class mit all den Möglichkeiten des std::string mit reingelinkt? Und in den Fällen wo du Exceptions wirfst stattdessen Errorcodes verwendest und diese an der aufrufenden Stelle manuell überprüft und jeweils in die entsprechenden Fehlermeldungs-Strings umgewandelt um die meldung auszugeben? Sonst vergleichst du Code mit guter Fehlerbehandlung gegen Code komplett ohne Fehlerbehandlung. Aber größer wird das Binary durch Exceptions selbstverständlich.

Embedded Windows ist natürlich nix für dein Projekt - aber nur weil es eine Linux Distro mit wenig Rambedarf gibt ist C nicht toller als C++.. das wollte ich nur sagen. Ich will hier auch als Linux Nutzer garantiert nich die Windows Flagge hochhalten aber nen Win7 und 1GB Ram hat einfach mehr Möglichkeiten als nen 128RAM Debian.. darum gings mir. Daran ist nicht Windows im Kern schuld sondern eher das Bereitstellen der vielfältigen Möglichkeiten. Ich kauf ja auch keinen Reisebus und ärger mich dann über den Verbrauch wenn ich damit doch nur zum Brötchen holen fahre