spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Blue Phoenix«

die Init Methode die kein Rückgabewert besitzt und protected ist

Private/protected Init-Methoden sind sehr üblich und haben auch nicht (oder nur beschränkt) die genannten Probleme. Öffentliche hingegen sind meistens keine gute Idee.

@NachoMan:
Auch von mir ein Danke für die Blumen. Aber ich sehe das gleich wie dot. Man muss mir nicht glauben (und tut das auch nicht einfach so), sondern lest meine Begründungen und mach euch selbst Gedanken über die Folgerungen und Konsequenzen. Abwägen was man schlussendlich benutzen will muss man sich immer selbst machen. Probiert auch wirklich Fehler in der Argumentation, Gegenbeispiele etc. zu finden. Erst dann fängt man auch zu verstehen warum man etwas so machen sollte. Kleines Beispiel: Zeiger vs. Referenzen. Es bringt nichts hier den Leuten Grundregeln einzuhämmern. Man muss die Unterschiede zwischen den beiden Verstehen und dann von Fall zu Fall entscheiden was man jetzt benutzen sollte. Das schöne daran ist, dass sich dann, wenn mans verstanden hat, die gleiche Vorgehensweisen wie bei allen anderen herauskristallisieren werden. Es gibt sehr viele Beispiele von solchen Sachen und darum ist das wichtigste, dass man etwas nicht einfach so macht, weil mans so "gelernt" hat, sondern weil man selbst überprüft hat, dass es das beste Mittel ist. Man sollte seine Entscheidungen also immer Begründen können. Und "weil ich das so gelernt habe" oder "weil der und der das so machen" zählt nicht.

//EDIT
Dass das auch wir ständig tun müssen sieht man bei C++ mit dem neuen Standard. Plötzlich gibt es neue, bessere Möglichkeiten gewisse Dinge zu erledigen und da müssen alle (auch ich sag jetzt mal erfahrenere Entwickler) sich genau die gleichen Dinge wieder erneut überlegen. Z.b: Wie gibt man am besten einen Container von Objekten zurück? Soll das jetzt eine Referenz, ein Zeiger oder eine Rvalue-Referenz werden? usw.

Ich werde denke ich meinen C++ Artikel hier in das Wiki hochladen. Da steht sowas unter anderem auf drin. Dann kann die betroffene Person einfach nachlesen und Beispiele anschauen. Ist zwar nicht direkt für die Spieleprogrammierung, aber jeder, der C++ macht, sollte sich das zu Herzen nehmen.

@dot, @drakon, @BlueCobolt: Wäre klasse, wenn ihr da mal draufschauen könntet. Ich bin der Meinung, dass das alles halbwegs vernünftig und aktuell ist.

EDIT: Ist doch etwas mehr Arbeit, weil ich den Artikel mit Personenbezug formuliert habe. Aber das erste Kapitel ist schon da:

Effektiv C++ für Spieleprogrammierer

Meiner Meinung nach sollte ein Softwareentwickler nur eine Sache prinzipiell ablehnen: Paradigmen !
Pauschal die Behauptung aufzustellen das globale Variablen, goto usw. von Teufel sind halte ich für falsch.
Es gibt immer bestimmte Situationen in denen sowas verpöntes hilfreich sein kann.
Man denke zum Beispiel an ein MUTEX oder einen Datenbankconnect. Alles potentielle Kandidaten für globale Objekte.
Man denke an mehrfach verschachtelte Schleifen aus denen ich in bestimmten Situationen aussteigen will.
Baue ich mir in jede Schleife eine Variable für den Abbruch ein oder springe ich mit goto direkt raus.
Exceptions in Konstruktoren sind auch ein heißes Eisen. Wenn ich ein Objekt auf dem HEAP anlege und im Konstruktor
noch andere Daten mit new initialisiere und dann eine Exception werfe, wie verhält sich dann das System ?
Ist Speicher allokiert ? Ist er nicht allokiert ? Wird der Destruktor aufgerufen ? Ist der Zeiger auf das Objekt = NULL ? usw.
Viele Embeded Systeme unterstützen C++ ohne Exceptionhandling, was dann ?

Was ich damit sagen will ist: Software ist so vielseitig und komplex das man immer von Situation zu Situation entscheiden sollte.

Zitat von »stef«

Man denke zum Beispiel an ein MUTEX oder einen Datenbankconnect. Alles potentielle Kandidaten für globale Objekte.

Nein. Ganz und gar nicht. Das sind perfekte Beispiele dafür, dass es KEINE globalen Objekte sein sollten. Wie oft stellt man fest, dass man eben doch nicht nur eine DB-Verbindung braucht, sondern mehrere. Sorry, aber da hast Du ganz ganz schlechte Beispiele angeführt.

Zitat von »stef«

Man denke an mehrfach verschachtelte Schleifen aus denen ich in bestimmten Situationen aussteigen will. Baue ich mir in jede Schleife eine Variable für den Abbruch ein oder springe ich mit goto direkt raus.

NEIN! Dafür gibt es BREAK und CONTINUE. Ein Goto ist da die absolut falsche Lösung. Auch eine Variable ist da meist unnötig.

Zitat von »stef«

Exceptions in Konstruktoren sind auch ein heißes Eisen. Wenn ich ein Objekt auf dem HEAP anlege und im Konstruktor
noch andere Daten mit new initialisiere und dann eine Exception werfe, wie verhält sich dann das System ?
Ist Speicher allokiert ? Ist er nicht allokiert ? Wird der Destruktor aufgerufen ? Ist der Zeiger auf das Objekt = NULL ? usw.

Das ist wohl definiert. Du solltest Dir dazu wohl die Definition des Standards oder ein gutes Buch zurate ziehen.

Zitat von »stef«

Viele Embeded Systeme unterstützen C++ ohne Exceptionhandling, was dann ?

C++ ohne Exceptionhandling? Beispiel bitte. Das ist dann irgendwas, sowas wie C++ ohne Klassen: Alles, aber kein C++. Von daher muss dort eine ganz andere Lösung gewählt werden, als für C++ üblich ist. Ist ja wohl auch logisch. Davon reden wir hier aber nicht, wir reden hier von C++ mit Exceptions. Nur weil irgendwo irgendwer eins der wichtigsten Konzepte der Sprache nicht verfügbar hat, ist das kein Grund eine gute Praxis auszuschlagen auf all den Systemen, wo es funktioniert.

Du magst durchaus Recht haben, dass fast jedes Konzept irgendwo eine sinnvolle Verwendung finden kann. Deine Beispiele sind allerdings Paradebeispiele dafür, wo man sie NICHT verwenden sollte.

Zitat von »stef«

Meiner Meinung nach sollte ein Softwareentwickler nur eine Sache prinzipiell ablehnen: Paradigmen !

Du meintest Dogmen!?

Zitat von »stef«

Pauschal die Behauptung aufzustellen das globale Variablen, goto usw. von Teufel sind halte ich für falsch.
Es gibt immer bestimmte Situationen in denen sowas verpöntes hilfreich sein kann.

Faustregeln sind nicht in Stein gemeißelte, universelle Gesetze, sondern Leitfäden für gute Praxis. Wer ihnen blind folgt ist nicht besser als wer sie ignoriert...

Zitat von »stef«

Man denke zum Beispiel an ein MUTEX oder einen Datenbankconnect. Alles potentielle Kandidaten für globale Objekte.

Potentiell möglicherweise ja, in der Regel aber eher besser nicht...

Zitat von »stef«

Man denke an mehrfach verschachtelte Schleifen aus denen ich in bestimmten Situationen aussteigen will.
Baue ich mir in jede Schleife eine Variable für den Abbruch ein oder springe ich mit goto direkt raus.

Oder du packst die innere Schleife in eine Funktion, was wohl sowieso angebracht wäre, da das Ding offenbar relativ komplexe Logik beinhaltet...

Zitat von »stef«

Exceptions in Konstruktoren sind auch ein heißes Eisen. Wenn ich ein Objekt auf dem HEAP anlege und im Konstruktor
noch andere Daten mit new initialisiere und dann eine Exception werfe, wie verhält sich dann das System ?
Ist Speicher allokiert ? Ist er nicht allokiert ? Wird der Destruktor aufgerufen ? Ist der Zeiger auf das Objekt = NULL ? usw.

Wenn du alles richtig machst, was in dem Fall bedeutet, dass diese im Konstruktor mit new angeleten Daten alle in entsprechenden RAII Objekten gehalten werden, dann wird alles korrekt aufgeräumt. Wenn in einem Konstruktor eine Exception fliegt, werden die Destruktoren sämtlicher, bis zu diesem Punkt vollständig konstruierter Unterobjekte aufgerufen. Da das Objekt selbst aber nicht vollständig konstruiert wurde, wird sein Destruktor nicht aufgerufen. Der durch den operator new für das Objekt anbgeforderte Speicher wird über den passenden operator delete freigegeben, bevor die Exception weiterfliegt. Da die new Expression nicht vollständig ausgewertet wurde, gibt es auch keinen Zeiger auf das Objekt, denn das Objekt existiert gar nicht, da es nie konstruiert wurde...

Zitat von »stef«

Viele Embeded Systeme unterstützen C++ ohne Exceptionhandling, was dann ?

Dort kann man Exceptions dann eben nicht verwenden. Aber nur weil es tatsächlich Bereiche wie manche Embedded Systeme oder Teile eines Betriebssystemkernels gibt, wo Exceptions aus bestimmten Gründen keine Option sind, heißt das noch lange nicht, dass man Exceptions im Allgemeinen nicht verwenden sollte...

Zitat von »stef«

Was ich damit sagen will ist: Software ist so vielseitig und komplex das man immer von Situation zu Situation entscheiden sollte.

Richtig, es ist immer besser, zu wissen was man tut. Ich denk da wird dir keiner widersprechen...

Zitat von »BlueCobold«

Nein. Ganz und gar nicht. Das sind perfekte Beispiele dafür, dass es KEINE globalen Objekte sein sollten. Wie oft stellt man fest, dass man eben doch nicht nur eine DB-Verbindung braucht, sondern mehrere. Sorry, aber da hast Du ganz ganz schlechte Beispiele angeführt.

Wenn ich versuche eine Exclusiv-Resource mit einem MUTEX / CriticalSection in 15 Threads zu schützen dann deklariere ich das Objekt global und mache es mit extern den jeweiligen Threadfunktionen zugänglich.
Das Objekt mühevoll 15 Threads per Zeiger zu übergeben ist völlig unsinnig, zeitaufwändig und unübersichtlich. Das selbe gilt für Datenbankverbindungen wenn diese von allen Threads benutzt werden.

Zitat von »BlueCobold«

NEIN! Dafür gibt es BREAK und CONTINUE. Ein Goto ist da die absolut falsche Lösung. Auch eine Variable ist da meist unnötig.

Ich hatte explizit von verschachtelten Schleifen gesprochen. Wenn du in der dritten Schleifenebene loopst und vor hast alle zu verlassen wird dir break wenig helfen.
Hier einen Konstrukt zu bauen das alle Schleifen ohne GOTO verlässt ist zeitaufwändig, mühevoll, unübersichtlich und oben drein noch fehleranfällig.

Zitat von »BlueCobold«

Das ist wohl definiert. Du solltest Dir dazu wohl die Definition des Standards oder ein gutes Buch zurate ziehen.

C++ ist so komplex das es Massig Grauzonen und Ungereimtheiten gibt. (siehe http://www.comeaucomputing.com/iso/cwg_active.html)
Unser alter Prof hat immer gesagt vermeidet Grenzwertige Bereiche von C++ wenn Ihr nicht gerade einen Allerweltskompiler wie VS benutzt.

Zitat von »BlueCobold«

C++ ohne Exceptionhandling? Beispiel bitte.

VERIX !!! Ein VeriFone Betriebssystem für Bezahlterminals. Unterstützt C++ mit STL und allem drum und dran. Nur keine Exceptions.

Zitat von »BlueCobold«

Du magst durchaus Recht haben, dass fast jedes Konzept irgendwo eine sinnvolle Verwendung finden kann. Deine Beispiele sind allerdings Paradebeispiele dafür, wo man sie NICHT verwenden sollte.

Globale Objekte benutze ich genau da wo dieses Applikationsweit einmal existiert und von vielen Modulen benutzt wird. Da ist der MUTEX DASSS Paradebeispiel für !

Zitat von »dot«

Du meintest Dogmen!?

Ich meine Paradigma im Sinne von Lehrmeinung, Denkmuster, grundlegende Weltsicht !
Aber du hast Recht. Dogma trifft es eher.

Zitat von »dot«

Faustregeln sind nicht in Stein gemeißelte, universelle Gesetze, sondern Leitfäden für gute Praxis. Wer ihnen blind folgt ist nicht besser als wer sie ignoriert...

Genau das was ich sage ! Ich vertrete nicht die Meinung das goto toll ist. Nur die Tatsache das es in der Vergangenheit schwer missbraucht worden ist (Code ala C64 usw.) heißt nicht das es heute geächtet werden muss.
Es hat bestimmt einen Grund das es goto in C# immer noch gibt. Das gleiche gilt für globale Variablen. Es gibt Anwendungsfälle da kannst du dich tot machen indem du ein und das selbe an hunderte Methoden/Funktionen übergibst. Ob das so Sinnvoll ist (auch im Bezug auf Lesbarkeit) muss von Situation zu Situation neu entschieden werden.

Zitat von »dot«

Oder du packst die innere Schleife in eine Funktion, was wohl sowieso angebracht wäre, da das Ding offenbar relativ komplexe Logik beinhaltet...

Das Problem mit dem Aussteigen bleibt, ob die Schleife nun komplex ist oder nicht. Und prinzipiell immer in eine Funktion packen ... weis nicht so recht. Auf Seite 64/65 im kernighan ritchie ist das Schleifenproblem als Beispiel für eine Sinnvolle Anwendung von goto in C angegeben.

Zitat von »dot«

Dort kann man Exceptions dann eben nicht verwenden. Aber nur weil es tatsächlich Bereiche wie manche Embedded Systeme oder Teile eines Betriebssystemkernels gibt, wo Exceptions aus bestimmten Gründen keine Option sind, heißt das noch lange nicht, dass man Exceptions im Allgemeinen nicht verwenden sollte...

Ich habe kein Wort davon gesagt das man Exceptions nicht verwenden soll. Ich selbst liebe die Dinger förmlich. Es ging um Exceptions in Konstruktoren und da gehen die Meinungen auseinander.

Zitat von »LetsGo«

Also im Embeddedbereich wird wirklich kaum mit Excetions gearbeitet und auch andere "luxeriöse" Dinge einer Sprache fallen raus (begrenzte Rechenkapazitäten) allerdings ist das ein ganz anderes Teilgebiet und das kann man eigentlich kaum zum Vergleich heranziehn. Meistens wird in reinem C programmiert und das dann noch mit ASM Optimierung.

Interessante Diskussion übrigends.

Was? Ich habe jetzt schon auf mehreren Embedded Systemen gearbeitet und mache das noch immer. Exceptions waren immer vorhanden, im jetzigen System läuft die Anwendung sogar unter Java. Soll nicht heißen, dass das überall so ist. Aber C und ASM ist heute wirklich nicht mehr oft anzutreffen. ASM schon echt gleich gar nicht.

Zitat von »stef«

Wenn ich versuche eine Exclusiv-Resource mit einem MUTEX / CriticalSection in 15 Threads zu schützen dann deklariere ich das Objekt global und mache es mit extern den jeweiligen Threadfunktionen zugänglich.

Das machst Du vielleicht so. Das heißt aber nicht, dass das eine gute Praxis ist.

Zitat von »stef«

Das Objekt mühevoll 15 Threads per Zeiger zu übergeben ist völlig unsinnig, zeitaufwändig und unübersichtlich.

Nein. Aber für globale Variablen trifft das aber zu.

Zitat von »stef«

Das selbe gilt für Datenbankverbindungen wenn diese von allen Threads benutzt werden.

Nein, falsch. Genau dafür gibt es Connection-Pools. Globale Variablen für Datenbankverbindungen in Threads sind so ziemlich die schlechteste Idee, die ich kenne.

Zitat von »stef«

Hier einen Konstrukt zu bauen das alle Schleifen ohne GOTO verlässt ist zeitaufwändig, mühevoll, unübersichtlich und oben drein noch fehleranfällig.

Nein. Goto ist unübersichtlich. Ist es schon immer gewesen. Wie dot schon sagte, deutet das eher darauf hin, dass Du einen zu langen Code hast, der sinnvoller in Funktionen aufgeteilt werden sollte. Genau das blockierst Du mit einem GOTO übrigens ganz schnell. ... Moment mal, reden wir hier ernsthaft darüber, ob man GOTO verwenden sollte? Ich meine... WHAT THE FUCK?

Zitat von »stef«

C++ ist so komplex das es Massig Grauzonen und Ungereimtheiten gibt. (siehe http://www.comeaucomputing.com/iso/cwg_active.html)

Da widerspreche ich auch nicht. Aber das Verhalten eines Konstruktors in welchem eine Exception geworfen wird, ist und bleibt wohldefiniert.

Zitat von »stef«

VERIX !!! Ein VeriFone Betriebssystem für Bezahlterminals. Unterstützt C++ mit STL und allem drum und dran. Nur keine Exceptions.

Gut, dann geht das dort eben nicht. Das ändert aber nichts daran, dass man es dort benutzen sollte, wo es geht. Nur weil es in einem speziellen System nicht geht, heißt das noch lange nicht, dass man es überall anders auch so bescheiden lösen sollte.

Zitat von »stef«

Globale Objekte benutze ich genau da wo dieses Applikationsweit einmal existiert und von vielen Modulen benutzt wird. Da ist der MUTEX DASSS Paradebeispiel für !

Mutex ist ein Paradebeispiel für eine statische Variable verwendet von schlechten Entwicklern. Es ist kein Paradebeispiel für eine globale Variable.
Ich z.B. würde selbst das anders lösen. Nämlich den Mutex oder die Semaphore VOR den Threads erzeugen und jedem Thread dies übergeben. Da braucht man weder eine statische, noch eine globale Variable.

Zitat von »BlueCobold«

Das machst Du vielleicht so. Das heißt aber nicht, dass das eine gute Praxis ist.

Stell dir vor du schreibst eine Applikation in der mehrere Threads auf ein Gerät zugreifen das über RS232/COM1 am Hostrechner angeschlossen ist.
Die Threads öffnen ab und zu mal COM1 senden was raus und schließen COM1 wieder. Um zu verhindern das es beim öffnen von COM1 kracht schachtelst du die Zugriffe in eine CS.
Bei zwei Threads übergebe ich die CS vielleicht noch als Pointer an die Threads einzeln. Bei 30 Threads möchte ich den Entwickler sehen der die CS nicht global deklariert.
Nenne mir einen vernünftigen Grund die CS irgend wo zu verbergen und via Zeiger an alle Threads einzeln zu übergeben außer "Weil man es so macht ..." !

Zitat von »BlueCobold«

Nein. Goto ist unübersichtlich. Ist es schon immer gewesen. Wie dot schon sagte, deutet das eher darauf hin, dass Du einen zu langen Code hast, der sinnvoller in Funktionen aufgeteilt werden sollte. Genau das blockierst Du mit einem GOTO übrigens ganz schnell. ... Moment mal, reden wir hier ernsthaft darüber, ob man GOTO verwenden sollte? Ich meine... WHAT THE FUCK?

Warum bezeichnen Bjarne Stroustrup, Dennis Ritchie und Brian W. Kernighan den Einsatz von GOTO exakt für dieses Beispiel als Sinnvoll ? (Ich gehe mal davon aus du weist wer die Herrn sind)
Warum ist GOTO immer noch Bestandteil von C# ?

Nochmal !!!
Ich halte hier kein Plädoyer für die Benutzung von globalen Variablen und goto.
Ich sage es gibt seltene Fälle in denen deren Einsatz sinnvoller ist, als auf Teufel komm raus zu versuchen Sie zu umgehen !

Bemerkung am Rande:
Es gibt auch einen großen Unterschied zwischen globalen Variablen (int, char usw.) und globalen Objekten die ihre Attribute durch eine Schnittstelle schützen !

Zitat von »stef«

Zitat von »BlueCobold«

Das machst Du vielleicht so. Das heißt aber nicht, dass das eine gute Praxis ist.

Stell dir vor du schreibst eine Applikation in der mehrere Threads auf ein Gerät zugreifen das über RS232/COM1 am Hostrechner angeschlossen ist.
Die Threads öffnen ab und zu mal COM1 senden was raus und schließen COM1 wieder. Um zu verhindern das es beim öffnen von COM1 kracht schachtelst du die Zugriffe in eine CS.
Bei zwei Threads übergebe ich die CS vielleicht noch als Pointer an die Threads einzeln. Bei 30 Threads möchte ich den Entwickler sehen der die CS nicht global deklariert.
Nenne mir einen vernünftigen Grund die CS irgend wo zu verbergen und via Zeiger an alle Threads einzeln zu übergeben außer "Weil man es so macht ..." !

Ehrlich gesagt klingt mir das ganze Beispiel ziemlich merkwürdig. Was genau macht es für einen Sinn, mehrere Threads auf die selbe COM Schnittstelle schreiben zu lassen? Spontan würd ich jedenfalls mal sagen, dass die Verwendung von Threads hier von vorn herein fehlgeleitet ist...