WinApi - OOP



  • 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
    - OnFinalInit

    Init:
    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
    Walter

    Edit: 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.



  • Daraus leitet sich per Definition ab, dass es besser geht.

    Es ist ja jetzt besser 🕶 Die Praxis ist immer noch der beste Lehrmeister.

    Und du hast kein einziges Argument gebracht

    Ich habe mein Model vorgestellt. Wenn Du kritisieren willst, dann musst Du Argumente liefern 🕶

    Jedenfalls braucht man keine Zombie Objekte.

    Das ist kein Argument sondern nur eine Behauptung.

    Ich bin gerne Bereit über mein Design zu Diskutieren aber bitte mit konkreten Vorschlägen und nicht mit irgendwelchen Standard Phrasen.

    Herzliche Grüsse
    Walter



  • kann mir denn mal jemand erklären wie so eine WindowListener Klasse wie z.B. in SFML funktioniert. ich blick da noch nicht so ganz durch.



  • Sagen dir Listener was? Ansonsten, lies dich in Events und das Observer-Pattern ein.

    Für sf::WindowListener konkret kannst du dir dessen Code anschauen.



  • Was die Klasse tut weiß ich. nur wie das funktioniert wollte ich wissen.
    ich hab mir den Code schon angeguckt blick da aber nicht ganz durch.
    Die haben da ne OnEvent funktion aber die wird nirgendwo definiert also nur declariert



  • darman96 schrieb:

    Die haben da ne OnEvent funktion aber die wird nirgendwo definiert also nur declariert

    Die Funktion ist rein virtuell. Vertiefe dich ein wenig in die C++-Grundlagen...



  • ja ich weiß man kann eine virtuelle methode überschreiben aber die frage ist wo in deren code wird das gemacht.



  • Woher sollen wir das wissen? Lade dir doch den Code herunter und schaue in an...



  • erstens hab ich mir den code angeguckt und es nicht gefunden und zweitens vllt weiß das ja doch jemand oder zumindest wie man sowas machen könnte.



  • darman96 schrieb:

    erstens hab ich mir den code angeguckt und es nicht gefunden

    Ich meine den ganzen Code von SFML. Es gibt Tools, die in Dateien nach bestimmten Zeichenfolgen suchen können (welche, hängt von deinem OS bzw. Editor/IDE ab).

    darman96 schrieb:

    oder zumindest wie man sowas machen könnte.

    Ich habe dir ja schon vorher einen Link gegeben, der das Prinzip von Listeners ausführlich erklärt. Ein bisschen darfst du dich auch bemühen, oder zumindest konkrete Fragen stellen...



  • o.o du hast mir keinen Link zu listener gegeben.



  • Einen Link dazu kannst du dir auf dieser Seite aussuchen.



  • Shade Of Mine schrieb:

    Du behauptest also nie Fehler zu machen.

    Bist du nicht perfekt? Schade fuer dich. Jetzt mal ernsthaft: Was hat A mit B zu tun? Warum sollen Init-Funktionen verteufelt werden? Warum soll ich ein Problem in ein Konzept (hier RAII) pressen, wenn es nicht passt?



  • knivil schrieb:

    Shade Of Mine schrieb:

    Du behauptest also nie Fehler zu machen.

    Bist du nicht perfekt? Schade fuer dich. Jetzt mal ernsthaft: Was hat A mit B zu tun? Warum sollen Init-Funktionen verteufelt werden? Warum soll ich ein Problem in ein Konzept (hier RAII) pressen, wenn es nicht passt?

    Weil es eine Fehlerquelle ist.
    Und es nebenbei den Code verkompiliziert.

    Du brauchst auch kein RAII um Zombie Objekte zu vermeiden. RAII ist nur ein System das automatisch Zombieobjekte verhindert.

    Manchmal wachsen solche Sachen - das ist verständlich. Ich warte auch Code der grottig ist und den ich sicher nicht refaktoren werde - aber man muss ihn deshalb nicht verteidigen 🙂


Anmelden zum Antworten