Das deutsche QBasic- und FreeBASIC-Forum

[28398]

[stevie1401]

Lol, eine sehr konstruktive Antwort^^
Ich habe nie behauptet ein guter Programmierer zu sein. Im Gegenteil. Ich mache alles über try und error, da ich weder Informatik noch sonst etwas in der Richtung gelernt habe.
Programmieren habe ich mir selbst beigebracht und ich habe auch leider keine Gelegenheit mal einen Programmierkurs zu machen, da es sowas in unserer Gegend nicht gibt.

Wie weit man mit "Versuch macht klug" kommt, kannst du hier sehen:
www.doko-lounge.de
Um dieses Projekt geht es übrigens auch in diesem Thread.
Dort "treffen" wir uns inzwischen täglich und das Spielen klappt - bis auf manchen serverseitigen Rausschmiss, 1a.
Das finde ich eigentlich für einen Anfänger gar nicht mal so schlecht

[28398]

Ich habe nie eine Aussage über deine Fähigkeiten treffen wollen. Großer globaler Zustand ist jedoch de-facto ein Designfehler, der sich jedoch meistens relativ einfach eliminieren lässt, aber meistens gar nicht erst auftaucht, wenn man bestimmte Designmuster nutzt (zugegebenermaßen sind viele von denen in Freebasic noch recht mühselig, da Vererbung nach meinem Kenntnisstand erst noch kommt), wie z.B. MVC (Model-View-Controller), welches sich – behaupte ich einfach mal – sicher auch in dein Projekt prima integrieren würde.

Unterm Strich eliminieren die meisten Patterns nicht nur globalen Zustand, sondern erfordern aktiv eine saubere Modularisierung und führen somit bei stringenter Umsetzung zwangsläufig zu saubererem, stabilerem und besser handhabbarem Code.

Dafür muss man auch nicht studieren oder professionell programmieren - nur machen und reflektieren. Wenn du dir deine Situation bzw. die deines Projekts anschaust, siehst du, dass du zwar grundsätzlich dein Pflichtenheft (Doko-Server und -Client) erfüllt hast, aber die Codebase Probleme hat (wie in diesem Thread deutlich wird). Das zeigt: Mit Trial and Error kommt man oft zum Ziel, aber zu welchem Preis? Oftmals durch eine unsaubere Codebase, die schwer zu warten und zu erweitern ist.
Jetzt ist also der Zeitpunkt gekommen ein Refactoring durchzuführen, bevor du versuchst weitere Funktionalität zu implementieren. Beim Refactoring gehen viele Leute z.B. so vor, dass sie sich ihre Codebase anschauen und danach ein großes Blatt Papier nehmen. Darauf wird dann eine UML-artige Struktur (Objekte, ihre Eigenschaften und Verknüpfungen) entworfen, die dann erstmal in Form von Interfaces (also Objektdefinitionen ohne Implementierung) notiert wird. Dabei fällt dann oft das eine oder andere Detail auf, welches so nicht gut implementierbar ist, wo also bspw. eine Ebene Indirektion zu viel oder zu wenig auftritt. Je nach Erfahrung kann schon der erste Entwurf gut sein, manchmal werden aber auch eine handvoll benötigt.
Danach wird die vorhandene Codebase gedanklich verworfen und erstmal die Verknüpfungen zwischen den Objekten implementiert, das ist idR. Funktionalität die weitestgehend mit Fleischcode nix zu tun hat. Darauf aufbauend ist es oft nur eine Sache von Stunden die vorhandene/sichtbare Funktionalität zu re-implementieren anhand der alten Codebase.
Am Ende sollte man eine sauber modularisierte und nach Designpatterns strukturierte, gut dokumentierte Codebase haben, die sich leicht und problemlos erweitern lässt.

[MilkFreeze]

Soso... Interfaces sind also "Objektdefinitionen" ohne Implementierung...

warum das gleich mehrfach falsch ist.... ach, lassen wir das...
_________________
Milch ftw

[28398]

So kann man sich das schon vorstellen, ja. Das das in Programmiersprachen, die Interfaces als Sprachfeatures bieten (Ich glaube Java hat das und PHP5 hat das auch?), natürlich etwas anders.

Letztendlich läuft es beim Konzept Interface trotzdem darauf hinaus, dass ich definiere, was für Eigenschaften und Methoden ein bestimmte Art von Objekten (mindestens) hat. In Freebasic kann ich das repräsentieren, indem ich einen UDT habe, der Methoden und Attribute ohne konkrete Implementierung definiert. Die Implementierung liefert man dann später nach, wenn man sieht, dass die ausgedachten Interfaces miteinander funktioneren können|werden.

[MilkFreeze]

In Objekt-orientierter Programmierung sind Interfaces lediglich Sammlungen von Methoden-Definitionen. Interfaces dürfen keine Attribute haben (woran sich AFAIK nur ABAP nicht hält) und können nicht instantiiert oder geerbt werden. Deswegen sind es auch keine Objektdefinitionen - denn Objekte sind Instanzen von Klassen. Moment... die können nicht geerbt werden? Ja, aber sie können Implementiert werden. Was der Unterschied ist, wird deutlich wenn man sich Mehrfachvererbung und die Probleme damit anguckt.

Freebasic kann übrigens Vererbung - aber lustigerweise keine Interfaces.

Wenn du von Klassen oder UDTs ohne Implementierung sprichst, dann stell sicher, dass du klarstellst das du das auf der Code-Ebene meinst und nicht von OOP sprichst. Denn in deinem vorherigem Post war der Kontext recht unzweifelhaft OOP - und dann wäre dein halber Post schlichtweg Falsch.

Wie man ohne Missverständnisse das bezeichnet, was du meinst... hmm... da fällt mir leider auch nichts ein. Zumal ich die Vorgehensweise etwas... ähm... kreativ finde. Warum nicht einfach ein stinknormales Software-Design schreiben und UML für deine "Interfaces" (*Hust*) nehmen? Ich meine, wo ist das Problem? Selbst für ne bestehende Anwendung kann ich problemlos noch Nachträglich ein DV-Konzept/Design schreiben und die Anwendung entsprechend anpassen, wenn ich im Konzept Verbesserungen einfließen lasse.

Und wenn ich mit dem Konzept/Design fertig bin, erst dann schreibe ich die erste Zeile Code - das beinhaltet auch Klassen- bzw UDT-Definitionen

Übrigens: Welches Design-Pattern kann man denn in FreeBASIC nicht umsetzen?
_________________
Milch ftw

[28398]

Ahhhhh, Haarspalterei ohne Alternativvorschläge — Gut, dann bin ich raus.

[MilkFreeze]

Magst du mir wenigstens noch auf meine Frage antworten?
_________________
Milch ftw

[stevie1401]

@RWK
Du schriebst:
Das klappt deswegen, weil ich mich nicht mehr in der CallBackroutine von TSNE befinde. Darum auch mein Umweg aus der TSNEPlay_Message Sub..die ja das Callback von TSNE bei Dateneingang ist....einfach die Nachricht an eine eigene Sub weiterzuleiten.
Moment mal...
Deine Sub checkMessage() IST doch in der Sub TSNEPlay_Message. Deshalb müsstest du eigentlich auch noch im geschlossenen Thread oder Mutex oder was auch immer das ist, sein.
Genau das hatte ich auch schon mehrfach probiert, allerdings aus der folgender Sub:

[ThePuppetMaster]

@RWK ne .. das is nicht richtig ... @stevie1401 richtig .... Ein Thread endet nicht damit, das man eine unter-sub oder andere funktion aufruft.

Mann kann dies damit vergleichen, das man pro verbindugn ein neues programm startet. Jedes Programm representiert dadurch einen eigenen Thread und handelt eine einzelne verbindung. damit die Programme (Threads) auch auf gemeinsame Resourcen zugreifen können, gibt es eben die möglichkeit (und das geht nru bei threads, und nicht bei realen mehrfach gestarteten programmen) via shared variablen informationen für alle threads verfügbar zu machen.

Allerdings, da diese threads quasi parallel laufen, muss man dafür methoden einführen, die den gleichzeitigen zugriff auf eine "globale" (shared) variable schützen.

Und, dies wird eben via "Mutexe" gemacht.

@stevie1401 ... bezüglich deinem code:

[stevie1401]

Ok, ich denke, das habe ich verstanden.
Ich konnte mit dem Code:

[ThePuppetMaster]

Ich habe das gefühl, das dir das prinzip von Mutexe noch nciht ganz klar ist.

Aber, erstmal zu dem V_CallBackPtr ...

Diese Variable ist (tsne abhängig) einfach nur ein Pointer, also ein zeiger, auf einen vom Programmierer optional definiertem Speicherbereich.

je nachdem, wie tsne eingesetzt wird, kann (muss aber nicht) man einen Speicher erzeugen, den man über die funktionen von tsne unverändert übertragen kann.

Vergleichbar mit einem Postboten, den man beauftragt einen brief an seinem gegenüber zu senden. Bei sich zu hause hat man einen aktenschrankt, in dem entsprechende akten liegen, welche den empfänger identifizieren.

sendet der gegenüber nun eine antwort zurück, dann kommt wieder ein postbote zu einem zurück. irgend jemand, denn man ja nicht kennt.

Um jetzt herauszufinden, von wehm dieser brief kommt, hat der postbote wiede diesen zettel dabei, den er nur bei diesem empfänger mit hat. alle anderen haben einen eigenen zettel.

auf diesem steht dann etwas drauf, das man frei definieren kann.

dieser zettel ist mit dem V_CallBackPtr gleichzusetzen.

man kann ihn nutzen, muss aber nicht. wenn man es aber macht, dann wird dieser zettel immer mitgebracht, und man kann ihn auswerten / nutzen.

Da in dem von dir genutztem code-beispiel dieser verwendung findet, gehe ich einmal stark davon aus, das diese technik der "gegenstellen-identifikation" genutzt wird.

V_CallBackPtr ist also der zettel. Dirt steht die adressedes speicherplatzen drin (Ptr = Pointer), der auf die akten (V_IPA, V_Data, ...) Zeigt. Man kann also direkt darauf zugreifen, ohne vorher nach der Akte (z.B. mit Do Loop / For Next) suchen zu müssen.

Es ist nur eine vereinfachung.


Bezüglich dem Mutex.

Nun ... ich hatte schonmal versucht dir das per PM zu erklären, versuche es aber hier nochmal etwas anders.

Die Variable "G_ClientMux" hält eine Identifikationsnummer zu einem Mutex. Sie hat nur diese aufgabe. Sie hat nichts mit eienr verbindugn selbst zutun.

Diese Mutex-ID-Nummer ist nötig, damit das Betriebssystem weis, um Welches Mutex es sich handelt.
Es können mehr als nur ein Mutex erzeugt werden. darum benötigt man eine Variable, welche die ID des erzeugten Mutex speichert.

[stevie1401]

Doch doch, ich befürchte, ich habe das einigermaßen begriffen.
Und somit kann man sagen, dass man in der Sub TSNE_NewData() keinen Mutex schützen kann,richtig?
Das bedeutet, dass die Nachricht, die in die Sub TSNE_NewData() reingeht, nicht geschützt werden kann, um sich so eine Kopie davon machen zu können.
Und es bedeutet dann wohl auch, dass ich die Nachricht, weil ich sie nicht Threadsicher schützen kann, nicht in der Hauptschleife weiterverarbeiten kann.

Oder gibt es irgendeine Möglichkeit meinen gottverdammten String in die Hauptschleife zu bekommen?
Mehr will ich doch überhaupt nicht.

Es liegt sicherlich an der Art meiner Programmierung, aber so kann ich TSNE wirklich für mein Projekt vergessen.
OK, das hätten wir dann ja nun.
Kann mir jemand ein Beispiel für WSAAsyncselect oder WSAEventselect in Freebasic geben?
Vielen Dank.

[ThePuppetMaster]

also, laut deiner aussage gerade, muss ich leider gegenteiliges behaupten. ich glaube, du hast es doch nicth so richtig verstanden

Du kannst durchaus ein Mutex anwenden, in der Sub. Und das Problemlos.

Übrigens, schützt man nicht ein Mutex, sondern man schützt einen Thread vor einem anderen MITHILFE von Mutexe.


MfG
TPM

PS: ich werde mal versuchen das grafisch aufzuzeigen.
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]

[stevie1401]

Danke für deine Mühe, aber das brauchst du wirklich nicht.
Ich möchte einfach nur den String MessageFromClient aus der Sub TSNE_NewData() in die Hauptschleife bekommen.
Langt mir vollkommen.
Wenns gehen sollte, dann schreibe mir bitte die Befehlscodezeile hier rein. Wenns nicht geht, auch ok.
Wie komme ich an die MutexID, um Mutexlock in der Sub TSNE_NewData( machen zu können. Mehr brauche ich doch gar nicht. Ich will einfach nur diesen String bearbeiten.

[ThePuppetMaster]

ganz oben (global) im programm einfügen

[stevie1401]

WOW, cool
Ich vermute mal ich muss in der neuen Sub TSNE_NewData() NICHTS machen, richtig?
Und der String, den ich verarbeiten möchte ist in der Hauptschleife .V_Data, oder?

Vielen Dank

[ThePuppetMaster]

richtig.

allerdigns, zerstört es die kompletten features die TSNE mitsich bringt. (Asynchronizität und parallelität)

Dadurch wird der gesammte ablauf serialisiert, was eigentlich absolut schädlich für einen server bzw. einer server-client kommunikation ist.

[stevie1401]

Jo, das verstehe ich ja auch. Aber gerade die Asynchronizität und Parallelität verhindert ja, dass ich ohne Chrashes meine Daten heile "nach Hause kriege".
Und wenn ich in meiner VerarbeitungsSub geschätzte 200-400x lock und unlock machen muss (was irre Fehlerquellen verursachen kann), erkenne ich keinen Gechwindigkeitsvorteil mehr.

[stevie1401]

Also ich habe das jetzt ungefähr so gemacht, wie du es vorgeschlagen hast, Puppet, nun tritt oft folgendes auf:
IDs werden DOPPELT vergeben (an den selben Spieler). Der Spieler ist dann doppelt im Spiel.
Obwohl Spieler zu 100% online sind, haben sie keine Verbindung mehr zum Doko-Server - was weder die Clients noch der Server merken und es keinen Meldungen diesbezüglich gibt.
Die Clients sind weiterhin per WSAAsyncselect mit dem Server verbunden.
Kann es daran liegen?

Selbst wenn ein Spieler, der doppelt drin ist, sich wieder ordnungsgemäß mit closesocket abmeldet (dann ist er erst mal weg) und er sich wieder neu anmeldet, so ist er dennoch gleich wieder doppelt zu sehen.

Was bewirkt der Befehl "DeAlloctae(TPtr)"?