C# für Fortgeschrittene

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • C# für Fortgeschrittene

      So da ich mich ja mal für den C# Bereich groß mache möchte ich auch mal fortführend etwas für die zwar nicht so breiträumig hier vorhanden aber schon erfahreneren Programmier der Sprache C# etwas bieten.

      Ein Blick hierrein lohnt sich garantiert noch einige male da ich ihn erweitern werde!

      Inhalt
      Get/set Variabeln (Properities)
      Binary/Ascii? Which should i use?


      Get/set Variabeln (Properities)


      Kommen wir erst mal zu den getter/setter Variabeln. Auch Properities genannt.

      Es handelt sich dabei scheinbar um ganz normale Feldtypen. Sind sie aber nicht!
      Sie bieten viele Vorteile gegenüber normalen Feldtypen.

      Man kann sie im Gegensatz zu Feldtypen jederzeit einfach aussetzen.
      Und noch viel wichtiger setzt man gleich Properities hat man nicht das Problem das man ein Feldtyp nicht zu einem Properity umwandeln kann. In gewissen Fällen werden diese nähmlich benötigt. Zum Beispiel wenn man sie validieren möchte.
      Sie biete noch einige weitere Vorteile aber die bekommt man selbst zu spüren sobald man mit ihnen Arbeitet.

      Seit der Version 3.0 des netFrameWorks ist es sehr einfach geworden solche Properities zu definieren.

      So sah es vor 3.0 aus:

      Quellcode

      1. public Crypt crypt;
      3. private int sessionId;
      5. public int SessionId
      6. {
      7. get { return sessionId; }
      8. set { sessionId = value; }
      9. }
      11. public Socket socket { get; set; }
      13. public AsyncCallback callback;
      15. private string ip;
      17. public string Ip
      18. {
      19. get { return ip; }
      20. set { ip = value; }
      21. }
      23. private Account account;
      25. public Account Account
      26. {
      27. get { return account; }
      28. set { account = value; }
      29. }
      31. private SessionKey sessionKey;
      33. public SessionKey SessionKey
      34. {
      35. get { return sessionKey; }
      36. set { sessionKey = value; }
      37. }
      Alles anzeigen
      Wesentlich kürzer und einfacher dank der Automatic Properities sieht es seit 3.0 so aus:

      Quellcode

      1. public Crypt crypt;
      4. public int SessionId
      5. {
      6. get;
      7. set;
      8. }
      10. public Socket socket { get; set; }
      12. public AsyncCallback callback;
      15. public string Ip
      16. {
      17. get;
      18. set;
      19. }
      22. public Account Account
      23. {
      24. get;
      25. set;
      26. }
      29. public SessionKey SessionKey
      30. {
      31. get;
      32. set;
      33. }
      Alles anzeigen
      Binary/Ascii? Which should i use?


      Kommen wir zu der viel zu wenig gestellten Frage welche Konfigurationsdateitypen man nutzt. Viel zu oft werden Konfigurationsdateitypen wie xml und weitere verwendet.

      Gravierender Nachteil dieser ist. Das sie sehr lange brauchen bis sie ausgewertet/ausgelesen wurden.

      Kommen wir also zu den Binären Dateitypen.
      Bei diesen Dateitypen gibt es keine Formatierung diese bestimmt ihr nähmlich selber. Es wird nur das geschrieben was geschrieben werden muss.
      Also die Größe des Blocks. Evt der name des aktuell gelesenen Blocks die Anzahl der Blocks und den Inhalt des Blocks.

      Erstellen kann man solche Dateien kinderleicht.

      Hier ein Beispiel für die LeseMethode die Schreibmethode wäre einfach der gegengesetzte Writer statt reader:

      Quellcode

      1. public Modifiers ReadModifiers()
      2. {
      3. Modifiers mod = new Modifiers();
      4. SimpleModifier simple;
      5. int smallcount = Readbyte();
      6. for (int k = 0; k < smallcount; k++)
      7. {
      8. simple = new SimpleModifier();
      9. simple.Name = Readbyte();
      10. simple.Bonus = Readbool();
      11. simple.Value = Readint32();
      12. mod.Add.Add(simple);
      13. }
      14. smallcount = Readbyte();
      15. for (int k = 0; k < smallcount; k++)
      16. {
      17. simple = new SimpleModifier();
      18. simple.Name = Readbyte();
      19. simple.Bonus = Readbool();
      20. simple.Value = Readint32();
      21. mod.Sub.Add(simple);
      22. }
      23. smallcount = Readbyte();
      24. for (int k = 0; k < smallcount; k++)
      25. {
      26. simple = new SimpleModifier();
      27. simple.Name = Readbyte();
      28. simple.Bonus = Readbool();
      29. simple.Value = Readint32();
      30. mod.Rate.Add(simple);
      31. }
      32. smallcount = Readbyte();
      33. for (int k = 0; k < smallcount; k++)
      34. {
      35. simple = new SimpleModifier();
      36. simple.Name = Readbyte();
      37. simple.Bonus = Readbool();
      38. simple.Value = Readint32();
      39. mod.Rate.Add(simple);
      40. }
      41. MeanModifier mean;
      42. smallcount = Readbyte();
      43. for (int k = 0; k < smallcount; k++)
      44. {
      45. mean = new MeanModifier();
      46. mean.Name = Readbyte();
      47. mean.Bonus = Readbool();
      48. mean.Min = Readint32();
      49. mean.Max = Readint32();
      50. mod.Mean.Add(mean);
      51. }
      52. return mod;
      53. }
      Alles anzeigen
      Binäre Datentypen haben also kurz zusammen gefasst den Vorteil. Sie sind nur das was sie sein sollen. Sind sehr schnell verarbeitbar und dafür das sie schwer lesbar sein mögen wir unroutinierte Nutzer. Ist es doch durchausmöglich Programme zum bearbeiten dieser zu schreiben. Mit nahe zu nicht vorhandenem aufwand. Oder man schreibt gleich einen Converter der zum Beispiel ne xml Datei in eine Binäre Datei umwandelt.

      Und wie ichbinniemand bereits sagte ebenfalls sehr wichtiger Punkt: die Programmierer regel #1: Vertraue niemals dem User.
      Der user kann jeder zeit etwas versuchen zu ändern, sei es bewusst oder unbewusst, binäre dateien machen das ganze schon schwieriger

    • Werbung zur Unterstützung des Forums ( Bitte AddBlocker deaktivieren )

    • Schönes Tutorial. Ich verstehe nur eins nicht so ganz.

      Um eine recht große Konfigurationsdatei zu parsen benötige ich im Mittel 27,61 Mikrosekunden (bzw. 0,00002761 Sekunden). Wenn ich die Konfigurationsdatei beim Start des Programms also parse und die Werte im RAM behalte, verzögert sich der Programmstart um 27,61 Mikrosekunden - eine Zeit, die also keine Rolle spielt.

      Der Start des Taschenrechners benötigt bei mir 70 Millisekunden. Würde er also noch die Konfigurationsdatei parsen, würde er sich um 0,039% verzögern.

      Nun empfiehlst du, eine eigene Klasse plus ein eigenes Programm zu entwickeln, um auf das "eigene Format" zugreifen zu können und die Werte ändern zu können. Wenn wir dabei von einem Zeitaufwand von einer Stunde ausgehen, könnte man in der gleichen Zeit 13 0387 540 mal die ini / xml Datei parsen. Das heißt, dass sich der Programmieraufwand erst nach über 13 Millionen Starts bezahlt macht.

      Inwiefern ist da das "eigene Format" mit dem Bearbeitungsprogramm berechtigt?

    • Du hast so ein spiel wie minecraft das spielstände mit mal locker 10mb schnell speichern und laden muss.

      B2T:
      Der wahre vorteil bei propertys ist aber das man vor dem schreiben in die variable noch ein paar änderungen oder überprüfungen vor nehmen kann.

      bei einer klasse z.b. immer zu erst sehen ob diese überhaupt exsitiert

    • Well;243642 schrieb:

      Schönes Tutorial. Ich verstehe nur eins nicht so ganz.

      Um eine recht große Konfigurationsdatei zu parsen benötige ich im Mittel 27,61 Mikrosekunden (bzw. 0,00002761 Sekunden). Wenn ich die Konfigurationsdatei beim Start des Programms also parse und die Werte im RAM behalte, verzögert sich der Programmstart um 27,61 Mikrosekunden - eine Zeit, die also keine Rolle spielt.

      Der Start des Taschenrechners benötigt bei mir 70 Millisekunden. Würde er also noch die Konfigurationsdatei parsen, würde er sich um 0,039% verzögern.

      Nun empfiehlst du, eine eigene Klasse plus ein eigenes Programm zu entwickeln, um auf das "eigene Format" zugreifen zu können und die Werte ändern zu können. Wenn wir dabei von einem Zeitaufwand von einer Stunde ausgehen, könnte man in der gleichen Zeit 13 0387 540 mal die ini / xml Datei parsen. Das heißt, dass sich der Programmieraufwand erst nach über 13 Millionen Starts bezahlt macht.

      Inwiefern ist da das "eigene Format" mit dem Bearbeitungsprogramm berechtigt?


      Das fängt an bei großen Datenmengen sich zu lohnen. Ein Beispiel als ich noch an den Aion Files saß gab es da die xml dateien die alle nutzten. Diese enthielten sämtliche Daten wie Dropdata usw.

      Parsen der xml files benötigte mehr als nur ein Paar mikrosekunden. Klar die waren auch alle zusammen mindestens 120 mb groß oder sogar größer.
      Die zu laden brauchte schon seine Zeit. So mit einem Convert dieser in eine Binäre Datei dauert der start nun nur noch eine Zeit die es sich nicht lohnt zu messen.

      Und alles in allem ist es einfach Professioneller Binäre Files zu verwenden. Im vorhinein zur Übersicht kann man das ja gerne mit xml machen aber es ist immer Ratsam die nachher in ein Binäres Format zu parsen.

      ichbinniemand;243651 schrieb:

      Du hast so ein spiel wie minecraft das spielstände mit mal locker 10mb schnell speichern und laden muss.

      B2T:
      Der wahre vorteil bei propertys ist aber das man vor dem schreiben in die variable noch ein paar änderungen oder überprüfungen vor nehmen kann.

      bei einer klasse z.b. immer zu erst sehen ob diese überhaupt exsitiert


      stimmt genau .D

    • ichbinniemand;243766 schrieb:

      mir ist grad aufgefallen das du noch das wichtigste bei binären dateien vergessen hast, die Programmierer regel #1: Vertraue niemals dem User.
      Der user kann jeder zeit etwas versuchen zu ändern, sei es bewusst oder unbewusst, binäre dateien machen das ganze schon schwiriger



      Stimmt da die meisten zu doof sind das zu verstehen wie einfach das auch eigentlich sei mag
      habs mal dazu geschrieben

    • Oh ha, na dann lade ich mir mal alle Parameter beim Start und schön ist es.

      Threadsicherheit ade, über Multiuser denken wir erst garnicht nach.

      Die Lebensdauer einer Variable ist so kurz wie möglich zu halten, weil sie ist variabel, sprich, sie kann sich ändern. Und das nicht nur durch mich. Folglich, wenn ich sie brauche, wird sie gelesen, wenn ich sie geändert habe, sofort weggeschrieben. Und jetzt sind wir wieder bei den gettern und settern.

      Damit habe ich nicht nur die Möglichkeit, 'ne Plausi zu machen. Ohne nachdenken kann ich bei einer geebten, includierten Klasse die Variable nutzen. Das Lesen und Schreiben, woher und wohin auch immer, implementiere ich in den Properities.