proggen.org

Hab ich nicht probiert, aber ich hab in die Funktion reingekuckt und die Fehlermeldung sagt eh schon alles:
Dataholding::AppendFile() und Dataholding::AppendFile() liefern per deklaration ein bool zurück, es gibt aber keine return anweisung.

Ok, das kann sogar sehr gut sein, die Funktionen stehen zwar drinnen, aber bis auf den Funktionskörper ist da noch nicht viel los, da noch nicht wirklich angefangen. Ich muss erst einen zusätzlichen Konstruktor für FileInfo bauen, bevor es bei der Datenhaltung weitergehen kann. Mir fällt dazu noch was ein, aber das setzte ich dir in den Buildsystem Thread

Ok, wenn du willst, kannst du es noch einmal mit VS versuchen, diese Fehler sollten jetzt behoben sein. Leider habe ich immer noch 74 Warnungen, die ich abarbeiten muss

Bebu hat geschrieben:Ok, wenn du willst, kannst du es noch einmal mit VS versuchen, diese Fehler sollten jetzt behoben sein. Leider habe ich immer noch 74 Warnungen, die ich abarbeiten muss

Ich habs gestern nochmal probiert und hatte 33 Compilerfehler
Ich habs so verstanden, dass das "Work in Progress" ist, und ich werd jetzt einfach abwarten. Arbeite du erstmal deine Warnungen ab

Also.
Dann machen se mal.

Hi. Ich weiß, du bist schon dran, aber hier nur zur Info die Fehler von MSVC:

Wollte mal wieder eine kleine Rückmeldung geben. Ich dachte die Datenhaltung wird ein Kleinigkeit im Vergleich zum Rest. Irren ist menschlich... Ich habe heute Feststellen müssen, dass ich den zugrundeliegenden SqliteWrapper komplett umbauen muss, weil Sqlite zu blöd ist Ich hatte einen Wrapper geschrieben, der die Daten im nativen Format herausholt. Aber Sqlite unterscheidet nur Text, Integer, Blobs. Jetzt hat natürlich der ganze Rattenschwanz über DataVariant und Co. überhaupt keinen Sinn mehr. unsigned long long und Co ist wohl am einfachsten als String abzuspeichern, und anschließend wieder umzuwandeln. Das ist vielleicht ein Blödsinn. Stunden von Arbeit für die Katze, das was ich jetzt brauche, hatte ich schon ganz am Anfang zur Verfügung. Lehrgeld ist manchmal bitter

cloidnerux hat geschrieben:http://www.johndcook.com/blog/2011/11/1 ... ogrammers/

+1

Das ist schade dass viel Zeit verloren gegangen ist. Aber bei solchen Kernkomponenten ist wichtig sie von "gscheit" zu machen, und jede ungereimtheit zu beseitigen. Wenn das Plumbing gut ist, gehts dafür in höheren Leveln schneller voran!

So. zumindest dieser Knoten ist jetzt entwirrt. Ganz nebenbei ist die Codebasis etwas schlanker geworden, weil der Rattenschwanz jetzt weg ist.

Ich habe von fat-lobyte vor ein paar Tagen einen Bug gemeldet bekommen. Enthält eine Pfadangabe ein Hochkomma, dann explodiert das zusammengesetzte Sql Kommando innerhalb von Sqlite. Das Hochkomma wird nämlich benutzt, um Strings in einem solchen Befehl zu kennzeichnen.
Ich habe drei Möglichkeiten, um darauf zu reagieren:
Escapesequenzen um solche Fehler im Pfadstring abzufangen
Pro:
Wohl die schnellste Lösung
Contra: Gibt es bei Sqlite überhaupt solche Sequenzen?
Die Umwandlung in diesen String resultiert bei Windows zu einem Problem, weil hier intern ein wchar benutzt wird und das sowieso störend auffällt.

Die Nutzung einer Serialisierungsbibliothek um den Zustand der Klassen direkt abzuspeichern.
Pro: Von Boost verfügbar.
Contra: Eine Datenbankänderung bedeutet, das jedesmal die gesamte Datenbank neu geschrieben werden muss.

Selbstschreiben eines Binärdateiparsers mit Jornalfunktion.
Pro: Flexibel und Platzsparend.
Contra: Hoher Aufwand, praktisch ein eigenes kleines Dateisystem nötig. Wie lässt sich so etwas gestalten, damit es wiederverwendbar ist? Boost::Spirit? Template Klassen?

Das waren meine Gedankengänge zum Thema bisher. Habt ihr noch eine andere Idee? Sonstige Anregungen?