spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »stef«

Zitat von »Sacaldur«

Multithreading:
und immernoch ist der Zweck mehrerer Threads nicht ganz klar
warum wird die Verarbeitung parallelisiert? was wird da denn (im Groben) verarbeitet?

Eigentlich wollte ich nicht so genau darauf eingehen, aber was soll es. Mein Baby ist ein Datenbank gestütztes Tool mit dem in unserer Produktion mehrere "Geräte" gleichzeitig programmiert werden.
Der Zugriff auf den an COM1 angeschlossenen Speicher ist dabei nur ein geringer Teil. Der Prozess des Programmierens läuft also Parallel ab um einen hohen Durchsatz zu erreichen.

was ist in dem Zusammenhang mit "Gerät programmieren" gemeint?
das Schreiben eines Programmcodes, Kompilieren dessen und Übertragen zum Gerät? (das würde ich mir zumindest darunter vorstellen)
wenn ja, dann macht es einerseits wenig Sinn, mehrere Personen gleichzeitig dies machen zu lassen und noch weniger, mehrere Threads dafür zu verwenden
allerdings scheinst du etwas anderes zu meinen: was genau meinst du damit?

Zitat von »stef«

Zitat von »Sacaldur«

Gegenfrage: Verwendet ihr bei euch automatisierte Test, wie Unit-Tests?

Nein !!!
Das System ist Objektorientiert aufgebaut. Das Hilft schon mal eine Menge bezüglich Erweiterung ohne Seiteneffekte.
Getestet wird indem ein Gerät programmiert wird und dieses dann zwecks Test zur Q geht.

ich verstehe die ablehnende Haltung nicht
wenn man die Tests automatisiert durchführt, kann man sicher sein, dass die getesteten Dinge auch funktionieren und man kann diese Tests beliebig oft nach jeder Änderung durchführen (wenn man denn will)
so vermeidet man, dass Fehler erst durch einen Tester manuell gefunden werden müssen

um konkreter auf die Unittests einzugehen:
speziell diese widersprechen nicht der Objektorientierung
Hintergrund ist der, dass jede Funktion/Methode, die man geschrieben hat, getestet werden soll
so kann man schon sehr früh herausfinden, ob nach Änderungen auch alle Bestandteile für sich noch richtig funktionieren
und wenn nicht, dann weiß man auch sofort, welche Funktion/Methode fehlerhaft ist
wenn alle Funktionen für sich funktionieren, ist es sehr wahrscheinlich, dass auch das Gesamtsystem funktioniert

bedenke bitte auch, dass Unittests auch nur eine Art von Tests sind, die nicht als Ersatz für andere Arten von Tests dienen

Zitat von »Sacaldur«

was ist in dem Zusammenhang mit "Gerät programmieren" gemeint?

Auf den Geräten läuft unmittelbar nach der Fertigung ein Urlader.
Die Geräte selber sind je nach Typ via RS232, USB oder LAN angeschlossen.
Das Verfahren ist ähnlich wie bei deinem Sat-Receiver beim Firmwareupdate.

Zitat von »Sacaldur«

ich verstehe die ablehnende Haltung nicht

"Nein !!!" soll einfach heißen machen wir nicht. Völlig wertfrei. Warum ich die Ausrufezeichen dahin gemacht habe weis ich nicht. War blöd.
Unittests sind mir ein Begriff. Als das Programm designed worden ist (um 2000 rum von meinem Vorgänger) war das nicht vorgesehen.
Anforderungen sowas nach zu rüsten gab es bisher nicht.

Zitat von »stef«

Weis auch nicht warum du immer beim dritten Post gleich auf 180 bist nur weil mal jemand was aderst sieht als du.

Das ist reine Interpretation deinerseits. Den Eindruck könnte ich ebenfalls von Dir gewinnen, wenn ich das wollen würde. Ich sitze hier ganz entspannt.

Schön, dass Du von Ausnahmen redest. Leider sind Deine Beispiele zur Verwendung der genannten Dinge ganz ganz schlechte. Gerade das mit den "Welcher Entwickler will das an 30 Threads übergeben" war... ein echter Griff in's Klo. Wir haben auf Arbeit einen gigantischen Server-Code und eine riesige eigene Test-Umgebung geschaffen. Da werden zu hundert immer wieder gleiche Objekte übergeben. Dennoch käme niemand auf die Idee diese global zu definieren. Hätte man das irgendwo gemacht, gäbe es ein riesiges Problem bei Erweiterungen.

Dass es in Java und C# globale Variablen gibt, ergibt sich allein schon aus dem Umstand, dass es public und static gibt. Kombiniert man das, kommt eine globale Variable dabei heraus. Es gibt sicher ganz seltene Situationen, wo diese Sinn machen. In fast allen Fällen (und gerade auch bei den von Dir angebrachten Beispielen) gilt das jedoch nicht.

Die Frage danach, warum goto in C# enthalten ist... Nun, es kann für Dinge verwendet werden, die sonst eine Variable oder Schleife mehr bräuchten. Aber genau das macht goto sehr fehleranfällig und schwer zu warten. Es baut technische Schulden auf. Dem Entwickler, der es verwendet hat, war völlig klar, was er damit macht. Seinem Nachfolger oder Kollegen aber nicht. Es wird zu schnell übersehen oder die Labels sind zu schwer zu finden. Es stört den üblichen Programmfluss. Meiner Meinung nach hätte C# an dieser Stelle lieber den Java-Weg gehen und es verbieten sollen. Goto führt leider eben fast immer zu sehr unübersichtlichem Code und letztendlich zu Fehlern.

Ich finde es doch sehr schade wie hier manche Diskussionen ausarten. Oft geht es hier im Forum wirklich nur um Grundsätze. Man möchte seine Meinung vertreten. Andererseits wird dann von reifen Programmierern die hinterfragen und möglichst noch ausprobieren gesprochen. Wenn dann andererseits andere Meinungen direkt zunichte gemacht werden, dann ist das alles sehr unglaubwürdig. Auf die Goto oder Init Diskussionen möchte ich gar nicht groß eingehen. Es wurde gesagt, dass man erst mal nichts verteufeln sollte. Wer gut überlegt und auch hinterfragt wird sowas wohl eher selten benutzen. Denke aber auch dass es immer mal wieder Situationen gibt in denen es verwendet werden kann.
Wie von vielen OO-Predigern wird auch hier im Forum meiner Meinung nach etwas zu viel designet. Ich konnte bis jetzt erst einblick in 3 Firmen haben und kann deshalb nur begrenzt darüber sprechen wie der Workflow bei einem normalen Softwareprojekt ist. Oft sind die Mittel und vor allem die Zet jedoch stark begrenzt. Da muss man schon mal Sachen programmieren die einem nicht gefallen. Auch das Argument von schlechtem Design auf welches man aufbauen muss finde ich gut. Hatten selbst schon so ein Projekt. Schlecht geplant und dann mussten wir zusehen. Da hätte ich auch am liebsten alles weggeworfen und ordentlich gemacht. Da gibts dann jedoch noch die Vorgesetzten die das nicht immer gleich sehen. Da geht die Kette immer weiter nach oben und irgendwer sagt halt dass die Zeit dafür nicht vorhanden ist.
Was hier also mal allgemein festgehalten werden sollte, gutes Design und Code nach Lehrbuch sind sicherlich was gutes und helfen weiter, können aber nun mal nicht immer benutzt werden. Hier geht es halt lediglich um eine Ausnahme. Wer diese aufnahmen nicht sehen will, soll es halt lassen und sein leben so wie bisher weiter führen
Zum Thema Lehrbuch. Schön dass hier ein Buch welches um Spieleentwicklung geht verteufelt wird, weil ein paar Dinge gemacht werden, welche nicht ganz so "schick" sind.
Schön dass hier im Forum sehr vielen Anfängern zu einem Buch geraten wird, welches die gleichen Fehler macht und sogar noch weiter ausführt. Als Beispiel nenne ich hier mal Singletons die verwendet werden. Der Unterschied zwischen den beiden Büchern ist der, dass man bei Game Coding Complete schon entwickeln können muss. Auch von Spieleentwicklung sollte man schon etwas wissen. Es ist halt gedacht für fortgeschrittene. Das hier im Forum so gelobte Buch ist an absolute Einsteiger gerichtet die noch keine Ahnung haben und von diesen Dingen noch nicht wissen das sie schlecht sind. Na wenn das kein Paradebeispiel dafür ist, dass es wohl manchmal wichtiger ist seine Meinung und seine Gedanken zu vertreten als zu versuchen andere Auffassungen und Gedanken, sowie allgemein neues zu verstehen und zu hinterfragen.

Das trifft natürlich nicht auf alle hier im Forum zu. Ausnahmen bestätigen die Regel.

Da möchte ich gerne noch anführen, dass, ich hoffe du hast mich nicht falsch verstanden, ich nicht Game Coding Complete als Anfängerbuch empfahl sondern viel mehr als Quelle für meine angefangene Diskussion mit dot. Das Buch ist keinesfalls Anfängerlektüre.

Ich vertrete im allgemeinen die Auffassung, dass auch wenn man Anfänger ist, und nicht gewahrt vor "Trugschlüssen" von alten Hasen aus C ist, dieses Wissen einfach erst einmal wertlos aufnehmen sollte. Man ist in dem Zustand sowieso noch nicht in der Lage zu werten.

Jeder Anfänger sollte einmal goto, Singeletons, oder den Geier benutzen um möglicherweise für sich selbst den Nutzen oder Unnutzen zu erkennen.

Im Übrigen - aufgrund der Tatsache, dass im Buch von Heiko Kalista überhaupt ein Singleton verwendet wurde, bin ich aufmerksam auf Design Patterns gewurden und habe Schlußendlich eine Facharbeit darüber geschrieben. Danke, Heiko ;-)

Sorry, wenn ich die Diskussion wieder aufwühle, aber ich bin da über etwas gestolpert, was ich nicht verstehe: Wieso sind Singletons schlecht? Ich arbeite bereits ein paar Jahre als Programmierer, aber das habe ich noch nie gehört. Klar sollte man sparsam mit Singletons umgehen, aber für Manager-Klassen o.ä. sind sie doch wie geschaffen. Oder gibt es eine bessere Alternative?

Btw: Das Buch Game Coding Complete lese ich zur Zeit ebenfalls. Über den Absatz zu Konstruktoren und Initialize Methoden habe ich mich dort auch gewundert, aber im Großen und Ganzen ist das Buch sehr empfehlenswert! Mike versteht auf jeden Fall etwas von Programmierung und Software-Architektur. Vor allem ist sein Schreibstil nicht ganz so umgangssprachlich wie der von Heiko Kalista ;-)

Manager-Klassen als globale und einzigartige Instanzen zu halten hat immer Nachteile, sobald es darum geht, dass man plötzlich mehrere unabhängige Fenster in z.B. einem Editor braucht, mehrere Threads, Views, whatever.
Singletons werden oft dazu benutzt um "scheinbar" eine statische globale Variable in OOP zu verpacken, was aber nicht der Fall ist. Ein Singleton sollte nur dann benutzt werden, wenn es von etwas nur eine einzige Instanz geben darf unter egal welchen Umständen. Manager gehören nicht dazu, sondern sind oft besser bei Dependency Injection aufgehoben.
Also ja, es gibt eine Alternative: Der Manager wird als normale Instanz durch die Anwendung erzeugt und an die Stellen weitergegeben, die ihn brauchen.

Hätte ich meine Manager als Singletons gebaut, hätte ich keinerlei Chance gehabt Plugins in meinen Editor zu integrieren, weil die sonst alle den selben Manager hätten verwenden müssen. Ein Manager als Singleton hat eigentlich immer nur Nachteile. Der einzige vermeintliche Vorteil ist der, dass man Singletons nicht überall hin übergeben muss, sondern es global verwenden kann. Das ist aber genau genommen kein Vorteil, sondern Faulheit. Meiner Meinung nach gibt es keinen rationalen Grund, warum man einen Manager global und statisch als Singleton entwerfen sollte, weil es mit Sicherheit keinen Grund gibt, der besagt, dass es einen Manager nur einmal geben darf.

Weil die Bedingung, dass man unter allen Umständen nur genau ein Objekt haben darf meistens einfach nicht stimmt und ein Singleton so tut, als hätte man kein globales Objekt und sich damit an alle guten Regeln gehalten, es dabei aber genau das ist.
Die bessere Alternative wäre also entweder ehrlich zu sein, und ein globales Objekt anzulegen, oder sich zu überlegen, wie man anders zurecht kommt.
Wobei ich immer der Meinung bin, das man es sich gut überlegen sollte einen komplizierteren aber dafür vielleicht schöneren Entwurf umzusetzen, nur weil der einen Vorteile bietet, von denen man eigentlich sicher ist, dass man sie in diesem Projekt nicht brauchen wird. Eine eingeschränktere Lösung kann da sinnvoller sein, wenn sie schneller zu programmieren und schneller zu verstehen ist.

Sicher, dass man es nicht braucht, kann man sich eigentlich nie sein. Es ist so oft der Fall, dass man das mal geglaubt hat und dann hinterher damit böse auf die Schnauze fällt Also lieber gleich richtig machen.

Ok, mal angenommen ich würde Manager nicht als Singleton implementieren, sondern sie an jedes Objekt übergeben, von dem sie gebraucht werden. Erstens würde das doch den kompletten Code sehr aufblähen, weil ich immer zig Objekte übergeben muss. Und zweitens könnte ich mehrere Instanzen von Managern erzeugen, was ich ja nicht möchte. Oder seh ich das falsch?