spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich möchte hier meine kleine private Library vorstellen.

Eine Dokumentation kann man hier finden.
Den Source Code findet man hier.

Diese Library ist entstanden, weil ich für mich privat nicht immer benötigte Klassen zwischen verschiedenen Projekten herum kopieren wollte.
Letztendlich ist sie eine kleine Ansammlung von Klassen, die teilweise aufeinander aufbauen.

Warum stell ich sie hier vor?
Letztendlich kann sie jeder verwenden. Ich halte den Master Branche ab jetzt auch auf einem konsistenten Zustand, Neuerungen kommen erst in Dev und wenn dort auch ein konsistenter Zustand erreicht wurde wird gemerged.
Allerdings würde mich interessieren, was ihr davon haltet? Ich fände es toll, wenn jemand mal über den Code und die Doku schauen würde, und eventuell Verbesserrungsvorschläge für mich übrig hätte.

Bisher ist der Großteil der Lib dokumentiert, der Rest wird morgen/die nächsten Tage folgen.

mfg

Du hast anscheinend nur in den Teil rein geschaut, der überarbeitungsbedürftig ist

Ich finde maximum<T>() ansprechender zu schreiben wie std::numeric_limits<T>::max().
Gleiches bei reverse.


Welche Typedefs findest du denn unsinnig?
TILE_SIZE ist tatsächlich noch ein Überbleibsel aus vergangenen Tagen, werde ich noch entfernen

Hallo Koschi,

ich hatte das damals alles als Template, hat sich aber in gewissen Dingen als eher unpraktisch herausgestellt, deswegen gehe ich jetzt diesen Weg.
Damit ich diesen ganzen redundanten Code aus den Point(3D) Klassen heraus bekomme, wäre vom Prinzip her, die +=, -=,... Operatoren als freie Funktion zu deklarieren. Hätte das denn irgendwelche Nachteile (außer das ich nicht direkt auf die Member zugreifen könnte)? Oder gäbe es einen anderen Weg?

Dann 2 Fragen die mir gerade auf der Seele brennen:
- inline: Ich habe gehört, dass der Compiler sowieso selbst entscheidet, ob er etwas inlined oder nicht. Wofür brauche ich denn nun dieses Keyword?
- static außerhalb von Klassen: Welchen Nutzen bietet mir dieses Keyword?

mfg

Zitat von »Koschi«

Zitat von »anti-freak«

ich hatte das damals alles als Template, hat sich aber in gewissen Dingen als eher unpraktisch herausgestellt, deswegen gehe ich jetzt diesen Weg.

Mich würde interessieren an welcher stelle sich das als unpraktisch herausgestellt hat.

Den genauen Grund kann ich dir leider auch nicht mehr nennen. Ich hatte Point eine sehr sehr lange Zeit als Template, habe mich dann aber schlussendlich dazu entschieden, kein Template zu nutzen.
Es lag dabei aber auch eher daran, das ich mich mittlerweile sehr an QT orientiere und mit Point(F) ein Äquivalent zu QPoint(F) geschaffen habe. Und da ich den Geometrie Namespace so gut es geht einheitlich halten wollte, habe ich mich für dieses Vorgehen entschieden. Ist aber auch kein Beinbruch, wenn jemand einen anderen Datentyp verwenden will, oder gar eine eigene Point Klasse für sein Rectangle nutzen möchte, muss er eben entweder einen typedef für RectangleBase setzen, oder richtig erben lassen. Beides ist kein großartiger Aufwand, da die Mainfunktionalität innerhalb von RectangelBase geschieht (natürlich müssen dann entsprechende Point Funktionen wie "getX" in diesem Point vorhanden sein, aber auch das ließe sich ja bei Bedarf lösen).

Zitat von »Koschi«

Zitat von »anti-freak«

Damit ich diesen ganzen redundanten Code aus den Point(3D) Klassen heraus bekomme, wäre vom Prinzip her, die +=, -=,... Operatoren als freie Funktion zu deklarieren. Hätte das denn irgendwelche Nachteile (außer das ich nicht direkt auf die Member zugreifen könnte)? Oder gäbe es einen anderen Weg?

Also die Diskussion die Operatoren als freie Funktion oder an die Klasse gebunden hatte wir hier schon mal, mit Keinem Klaren Ergebnis (meiner Meinung nach).

Wie gesagt mein Weg wäre alles in eine Template Klasse packen. Vielleicht mal hier spicken bei der SFML.

Gruß Koschi

Ich habe mal einen neuen Thread erstellt, da ich den Thread ungern mit Fragen zu generellen C++ Funktionalitäten vollmüllen möchte
Allerdings danke für den Link, habe mir das mal durchgelesen aber so wirklich weiter geholfen hat mir das nicht. Aber immerhin weiß ich jetzt, dass ich mit meiner Verwunderung über freie Operatoren nicht alleine stehe

mfg

So, nachdem ich mir gestern nochmal Gedanken gemacht habe, warum ich eigentlich von den Templates abgerückt bin, habe ich mich daran erinnert, das ich entsprechende Operatoren und Funktionen für Point und PointF anders implementieren wollte. Ich kannte Template Spezialisierung bedingt, wusste aber nicht genau, wie mir das in diesem Fall von Nutzen sein konnte.
Jetzt habe ich mich gestern noch ein wenig mehr damit beschäftigt und bin zu einem, wie ich finde, gutem Design gekommen.

Ich nutze jetzt also wieder Templates, allerdings mit Spezialisierung für float und double (nur bei der Point Klasse).
Vll mag jemand nochmal drüber schauen und eine neue Bewertung für den Geometrie Namespace abgeben? Ich wäre euch sehr dankbar

mfg

EDIT: Die Doku wurde natürlich noch nicht angepasst. Wird im Laufe der nächsten Woche aber auf jeden Fall passieren

Guten Tag,

Signal.h
Receiver.h
Receiver.cpp
Connection

ich habe diese Woche versucht ein Listener Pattern auf die Beine zu stellen.
An sich ist das ja nicht sonderlich kompliziert zu erstellen, allerdings gibt es ein paar Dinge, die andere Implementierungen ignorieren.

Das größte Problem ist eigentlich die Tatsache, dass sich Connections auch während das Signal in der "emit" Phase ist, lösen können.
Das ist mir vor allem bei der "SigSlot" Implementierung aufgefallen.

Deswegen habe ich jetzt meine eigene Implementierung geschrieben. Die Kernkriterien sind folgende:

- sicheres connecten und disconnecten während des emits
- signal und receiver sollen move und copy able sein
- keine aufräumarbeiten von außen

Allerdings haben die obigen Punkte auch ihren Preis, weswegen ein bisschen Overhead verursacht wird.
Beim disconnecten einer Connection wird diese nicht direkt gelöscht, sondern nur in einen invaliden Status gebracht, den ich beim emiten abfrage.
D.h. es wird teilweise über nicht mehr benötigte Connection iteriert.
Gelöscht werden diese Connections beim Aufruf von signal::emit, jedoch bevor in die eigentliche emit Schleife eingetreten wird.
D.h. im schlechtesten Fall (wenn alle Connections valid sind) muss über jede Connection 2 mal pro signal::emit iteriert werden.

Wie funktioniert das Ganze jetzt eigentlich genau?
An für sich nicht sonderlich kompliziert.
Um eine Connection zu erstellen, benötigt man 2 Dinge:
- ein signal
- einen Receiver

Zuerst einmal zum Receiver:
Ein Receiver bietet entsprechende Funktionen an, die von außen aufgerufen werden können (die so genannten Slots). Um das zu erreichen müssen diese Funktionen entweder public sein, oder die Klasse "signal" als friend deklariert werden.
Ein Receiver meldet sich selbst bei den Signalen, wenn der Destructor aufgerufen wird. D.h. hier sind keine manuellen Aufräumarbeiten von Nöten. Move und copy ist ebenfalls automatisiert.
Damit eine Klasse signale Empfangen kann, muss sie von "Receiver" erben.

Signal:
Signal ist eine variadic template Klasse. Dadurch können beliebig viele Parameter an sie gebunden werden, die später von den Slots erwartet werden. Es ist im Prinzip das Kernstück des ganzen. Ein Signal informiert alle Receiver mit denen es verbunden ist, wenn es sich verändert (move, copy, delete).

Wie nutzen wir das Ganze nun?

Folgendes Beispiel:


Eigentlich komplett simpel und wie man es erwarten könnte.

Allerdings ist das Ganze bisher nicht thread safe, daran arbeite ich gerade. Vll hat dazu ja jemand Vorschläge?

mfg

PS: Eine Dokumentation findet ihr hier: http://doc.simple-world.org/group__sigslot.html