WinApi - OOP
-
darman96 schrieb:
2. Ich weiß das ich das nich machen MUSS und das es das schon gibt aber ich will es trotzdem machen und zu dem Satz "Write games not game engines" kann ich nur sagen: wenn alle sich daran halten würden hätten wir heute nicht sehr viele engines mit denen man spiele machen könnte

Stimmt. Dann hätten wir viele gute Engines, mit denen man Spiele machen könnte. Aber da sich leider nicht alle da dran halten, haben wie viele gute Engines, mit denen man Spiele machen könnte und Millionen von Schrottengines, mit denen man gar nichts machen kann.
Wenn es doch bloß eine Methode gäbe, Wissen von Generation zu Generation weiter zu geben, damit nicht jeder Neuling immer wieder die gleichen Fehler wiederholt
. Das wurde die Menschheit wirklich weit vorwärts bringen.
-
SeppJ schrieb:
Wenn es doch bloß eine Methode gäbe, Wissen von Generation zu Generation weiter zu geben, damit nicht jeder Neuling immer wieder die gleichen Fehler wiederholt
. Das wurde die Menschheit wirklich weit vorwärts bringen.http://www.ted.com/talks/aubrey_de_grey_says_we_can_avoid_aging.html

-
-.- Nicht dein Ernst oder

Außerdem wer sagt denn, dass ich eine GameEngine machen möchte.
-
darman96 schrieb:
Außerdem wer sagt denn, dass ich eine GameEngine machen möchte.
Niemand. Du möchtest eine Genric Abstract Application Framework Manager Class Factory schreiben. Noch viel schlimmer.
-
So bin ich halt

Können wir jetzt zum Thema zurück?
Ich würde die Events/Messages gerne in einer eigenen Klasse abfangen, hab aber keine Ahnung wie. Könnte mir jemand ne kleine Beispielklasse geben oder so?
-
cooky451 schrieb:
knivil schrieb:
Ich habe beispielsweise gerade diese Methode mittels init fuer ein aktuelles Problem gewaehlt. Ist quasi ein einfachres placement new.
Interessant, kannst du das näher erleutern?
Immer dann, wenn du einen Objektpool hast (beispielsweise in einem statischen Array oder ein vom Benutzer beeitgestellter Speicherbereich) und den Speicher nachnutzen moechtest. Ein einfaches
init_withversetzt diesen Speicher in ein gueltiges Objekt. Hinzu kommt noch, dass diese Objekte PODs sein sollen. Dafuer gibt es zwei Anwendungszenarien: a) Performance b) embedded, oder beide gleichzeitig.
-
Mir ist schon klar wie placement new funktioniert. Was mich interessiert, ist der Fall in dem eine Klasse eine init() Methode hat mit der das Objekt initialisiert wird.
-
self quote for the win.
Ist quasi ein einfachres placement new.
Bitte stelle deine Frage neu. Warum wird init einem placement new vorgezogen? Weils 'nen POD sein soll und er trotzdem etwas aehnliches wie einen Konstruktor haben soll. Wenn dich der Name "init" stoert, wie waere es mit "reset". Beispiel: Zustandsautomaten in einen definiert Zustand/Anfangszustand bringen. shared_ptr oder unique_ptr haben reset. Also ein placement new auf den Speicherbereich wuerde ich nicht machen.
-
Könntet ihr das nicht ein andernmal ausdiskutieren?
-
darman96 schrieb:
Könntet ihr das nicht ein andernmal ausdiskutieren?
Ne.
darman96 schrieb:
Ich würde die Events/Messages gerne in einer eigenen Klasse abfangen, hab aber keine Ahnung wie. Könnte mir jemand ne kleine Beispielklasse geben oder so?
Du baust dir eine Systemunabhängige event Klasse, "übersetzt" alles und machst dir eine handle_event Methode. Oder, wenn dir APIUnabhängigkeit egal ist, machst du die Methode halt direkt so. Wo's Problem?
@knivil
Ich verstehe immer noch nicht wo da wie eine init() Methode passen würde. Codebeispiel?
-
cooky451 schrieb:
Ich verstehe immer noch nicht wo da wie eine init() Methode passen würde. Codebeispiel?
Ich glaube du stellst dich dumm, deswegen investiere ich keine Zeit in ein Codebeispiel fuer dich. Gegenfrage: Warum sollte da keine Init-Funktion passen?
-
knivil schrieb:
Gegenfrage: Warum sollte da keine Init-Funktion passen?
Keine Ahnung, ich verstehe ja nicht mal genau was deine Init() Methode da genau machen soll, klingt für mich alles völlig sinnlos. Daher ja meine Frage.
-
knivil schrieb:
Gegenfrage: Warum sollte da keine Init-Funktion passen?
Z.B. weil man keinen Weg hat, um sicherzustellen, dass diese Init Funktion auch tatsächlich aufgerufen wird, weil man, wenn Init() fehlschlagen kann, potentiell Zombies hat etc.
Von wegen "make it easy to use an interface right and make it hard to use it wrong" hat der Konstruktor also schonmal definitiv auch einen rein objektive Vorteile, ganz davon abgesehen, dass es natürlich wesentlich eleganter ist...
-
weil man keinen Weg hat, um sicherzustellen, dass diese Init Funktion auch tatsächlich aufgerufen wird
Wenn ich sie in meinen Code schreibe, dann bin ich sicher, sie wird aufgerufen.
hat der Konstruktor also schonmal definitiv auch einen rein objektive Vorteile
Haeh, irgendwie sehen viele nur schwarz und weiss. Das ist kein Plaedoyer gegen Konstruktoren sondern gegen "das ist ein Designfehler ... du hast nix verstanden .. religioeses RAII". Es gibt viele Situationen, wo init Sinn macht. Beispiele sind genannt.
-
knivil schrieb:
Beispiele sind genannt.
Nope, du hast nur behauptet, du hättest ein Beispiel. Was du beschrieben hast kann durch einen entsprechenden Ctor und einen op= erreicht werden => kein init(), keine Alarmsirenen, rote Fahnen etc.
-
knivil schrieb:
weil man keinen Weg hat, um sicherzustellen, dass diese Init Funktion auch tatsächlich aufgerufen wird
Wenn ich sie in meinen Code schreibe, dann bin ich sicher, sie wird aufgerufen.
Du behauptest also nie Fehler zu machen. Und auch niemand der deinen Code je benutzen wird, wird je einen Fehler machen.
Klingt vernünftig.
-
Ich habe ein Beispiel

Unsere Basisklasse für Models (Klassen die etwas tun) hat die folgenden Initialisierungs Methoden:
- Init
- OnPostConfig
- OnPostUICreate
- OnPostLoadParameter
- OnFinalInitInit:
Wird vom Framework aufgerufen nachdem alle Klassen instanzen erzeugt wurden. Üblicherweise werden in der Init Funktion die Signal Verbindungen zu den Partnerklassen aufgebaut. Es ist zB. eine gute Idee, wenn die Klasse Kontaktierung und die Klasse Handler sich ihren Status gegenseitig mitteilen können weil Kontaktierung geschlossen und Handler Move sonst einen ziemlichen Schaden anrichten können.OnPostConfig:
Wird vom Framework aufgerufen nachdem das Config.xml File eingelesen wurde. Hier werden die DIO's und AIO's zugeordnet und die Messgeräteinstanzen erstellt und die Messgeräte konfiguriert.OnPostUICreate:
Wird vom Framework aufgerufen nachdem das UI erstellt wurde. Hier werden die Threads gestartet welche mit dem UI interagieren.OnPostLoadParameter:
Wird vom Framework aufgerufen nachdem das Parameter File geladen wurde. Erst nach dem Laden des Parameter Files sind alle Infos vorhanden um die Applikation endgültig zu Initialisieren.OnFinalInit:
Wird vom Framework aufgerufen wenn alle Klasseninstanzen vollständig initialisiert und Parametrisiert sind. Hier wird zb. die Kontaktierung geöffnet und dann die Referenzfahrt des Handlers gemacht.Man kann das sicher auch anders lösen. Aber diese Lösung hat sich jetzt seit 10 Jahren bewährt und als sehr simpel an neue Anforderungen anpassbar erwiesen.
Herzliche Grüsse
WalterEdit: Rechtschreibung
-
weicher schrieb:
Man kann das sicher auch anders lösen.
Exakt.
Ich sehe hier zB keinen Grund warum der Ctor ein Zombie Objekt erstellen muss.
PS:
Das Model wirkt etwas überladen.
-
Exakt.
Beispiel bitte
Ich sehe hier zB keinen Grund warum der Ctor ein Zombie Objekt erstellen muss.
Wie würdest Du denn zB. die Zuordnung der DIO's machen unter der Voraussetzung dass bei einem bestehenden laufenden Programm eine andere Digital IO Karte nur durch ändern der Konfiguration eingebaut werden kann weil die Originalkarte nicht mehr lieferbar ist? Gilt analog auch für Messgeräte, Motioncontroler, Kameras usw. usf.
Das Model wirkt etwas überladen.
War Anfangs schmaler ist durch die Praxis gewachsen.
Herzliche Grüsse
Walter
-
Du sagst ja selber dass es größer geworden ist als ursprünglich geplant. Daraus leitet sich per Definition ab, dass es besser geht.
Und du hast kein einziges Argument gebracht warum der Ctor ein Zombie Objekt erstellen muss. Dass es eine Lade-Funktion gibt um Parameter zu laden oder dergleichen, ist hier ja kein Problem. uU macht es zB aber auch Sinn bei einer Änderung der Konfiguration das alte Objekt zu killen und ein neues zu erstellen.
Jedenfalls braucht man keine Zombie Objekte.