Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
2c und Master: abschließender Test
Hallo!
Sitze gerade hier noch am Stresstest der 2c, die anderen Tests laufen wunderbar.
Kann mir jemand von Euch vielleicht Wort für Wort schildern, wie genau das Speichern des Masterrecord gemacht wird.
Wenn der Master auf eine Seite passt, einfach manager->putMasterRecord()
Wenn der Master nicht auf eine Seite passt:
In welcher Reihenfolge muss ich dann die Teile speichern, und welcher Teil kommt dann unter manager->getMasterRecord()?
Allgemeine Frage zu put: Ich speichere ja erst den letzten Teil und danach die restlichen Teile, der erste Teil wird schließlich zuletzt gespeichert, richtig?
Könnte mir das jemand kurz erläutern? Bin hier fast schon am verzweifeln
Danke
Ich glaube, du denkst viel zu kompliziert!
Ein [m]putMasterRecord()[/m] ist nichts anderes als ein [m]modifyRecord()[/m] auf den Eintrag m[/m].
Das ist bei mir ein Zweizeiler: 1. TID bauen, 2. [m]modifyRecord()[/m] mit dieser TID aufrufen.
Selbiges gilt für [m]deleteMasterRecord()[/m], da ruft man dann halt [m]modifyRecord()[/m] mit einem leeren, 4 Byte großen [m]DataChunk[/m] auf.
Wieso eigentlich 4 Byte?
Das steht so in der Dokumentation und ist eigentlich auch ganz einfach nachzuvollziehen.
Der FragmentTIDManager verwendet genau ein Byte als Flag. Jetzt könnte er natürlich einen genau 7 Bytes großen Dummy schreiben, um den Eintrag auf die TID-Größe zu bekommen.
Er schreibt aber stattdessen einen [m]int[/m], weil man den wesentlich leichter auf 0 überprüfen kann als einen 7 Bytes großen Speicherbereich. Und da sich ja der TIDManager darum kümmert, dass jeder Eintrag mindestens 8 Bytes lang ist, interessieren die drei übrigen Bytes niemanden.
Hallo,
ehrlich gesagt halte ich das für ziemlich zweckbefreit. Der FragmentTIDManager kann nämlich einfach den Masterrecord vom TIDManager initialisieren lassen und sich einen Dreck drumrum scheren. Auch ob der Masterrecord existiert kann man bequem den TIDManager fragen.
Schlussendlich muss man nur noch im Modify den Fall, dass in den Flags 0 steht, anstelle von ‘n’ und whatsoever, so behandeln, wie eine nicht fragmentierte Seite.
Das wäre alles schön und toll… jedoch:
Leider sind die Testskripte so bescheuert, und wollen 4 Nullbytes. Also muss man für den Fall !TIDManager::existsMasterRecord() halt selber mit calloc einen 4-Byte Char-Array mit calloc anlegen und zurückgeben.
Wohl immer noch weniger Aufwand als der andere Blödsinn.
cu
Ford Prefect
Ich glaube, am allerwenigsten Aufwand ist es immer noch, wenn man sich nicht mordsmäßig Gedanken über das Für und Wider dieser Konzeption macht, sondern sie einfach als gegeben hinnimmt und in Gott’s Namen die paar Zweizeiler hinklatscht. Das sollte inklusive Neukompilieren eine Sachen von maximal 5 Minuten sein.
Das ist eine interessante These. Aber ehrlich gesagt halte ich diese Konzeption immer noch für ziemlich zweckbefreit.
Und das hat nix damit zu tun, wie viel Zeit man dafür braucht das hinzuklatschen. Ich muss(te) das nämlich so oder so nicht hinklatschen.
Ich sehe das so: Wenn ich mich über jeden Mist bei Aufgabe 2 aufregen würde, angefangen bei Rechtschreibfehlern über ungenaue/missverständliche Dokumentation und dumme Konzeptionen, bis hin zu ihren schlimmen “Coding Conventions”, dann hätte ich längst ein Magengeschwür.
Da lass ich lieber den großen Phlegmaten raushängen und sehe über solche Kleinigkeiten wie die Sache mit dem Dummy hinweg, zumal gerade diese Konzeption für mich wesentlich nachvollziehbarer ist als viele andere Dinge.
Auch ich hab besseres zu tun, als mich jahrelang bei SOS2 über jeden Mist aufzuregen, nachdem ich die Veranstaltung schon seit 2003 “beobachte”.
Ok, ärgern tut mich da schon einiges, wobei es aber nichts bringt, jeder Kleinigkeit nachzulaufen, sondern man nur längerfristig etwas ändern kann. Deswegen war ich schon beim KMW, habe mit dem Team kommuniziert (in dem ich selbst einmal war) und setze mich dafür ein, dass Mittel aus den Studiengebühren eine Wiederholung der Übung im Sommersemester ermöglichen.
Soviel zu dem Thema.
Ich hatte nur die Sache mit den 4 Bytes mitbekommen und nachgefragt was das soll. Dabei ist mir aus Versehen ohnehin vorher schon aufgefallen gewesen, wie bequem man den MasterRecord eigentlich handlen kann. Dummerweise habe ich jetzt den Fehler begangen, das auch gleich spontan ins Forum zu setzen, weils es mich überrascht hat, auf welch ungeschickte Art und Weise die Aufgabensteller die Sache nur unnötig verkomplizieren (Randnotiz: Den FragmentTIDManager auf den TIDManager aufzusetzen ist ja auch Quatsch, erleichtert aber ungemein die Aufgabe c).
Im Übrigen ist die Dokumentation ja nicht nur ungenau/missverständlich, sondern oftmals auch schilchtweg falsch 
cu
Ford Prefect