ThreadDB - memory file mapped container manager
-
Oft besteht die Notwendigkeit größere Datenmengen in stl containern zu verwalten. Das kann dazu führen, dass der Hauptspeicher nicht ausreicht.
Eine Erweiterung die Daten auf Platte auszulagern ist dann oft nur aufwändig zu lösen. Eine Möglichkeit hierzu sind Datenbanken. Diese zu integrieren idt oft schwierig und mit zusätzlichem Verwaltungsaufwand zum Bezrieb verbunden.
Daher haben wir eine einfache Lösung geschaffen, die es ermöglichen soll die Hauptspeicherlimitierung mit wenig Aufwand zu beseitigen. Die Library ist kostenfrei. Wir freuen uns immer auf Feedback.Freundliche Grüße,
Das ThreadDB Team
-
-
Hallo Docsoe,
momentan ist die Version für 64bit compiliert. Wenn es notwendig ist, kann auch 32 compiliert werden (mit etwas Testvorhalt).
Der Download ist unter:
https://sourceforge.net/projects/threaddb/Wir freuen uns immer über Feedback jeder Art.
Viele Grüße,
The ThreadDB Project
-
Wo ist da der Code? Da gibts eine Activity "imported Code", aber der Link führt ins Leere.
-
Hallo Mechanics,
die Archivdateien finden sich unter dem.Punkt "Files":
https://sourceforge.net/projects/threaddb/files
Bei Problemen mit dem Download bitte kurze Info.
Freundliche Grüße,
ThreadDB
-
Warum ist der Code nicht richtig verfügbar, wie bei allen anderen Projekten auf SF? Oder ist das kein Open Source Projekt?
In dem Archiv sind auch nur paar Header, ist das der ganze Code? Habs mir nicht genau angeschaut, kanns mir aber nicht vorstellen.
-
@Mechanics In den Archiven ist auch kein Sourcecode der Library.
-
Hallo,
der Sourcode ist für Mitwirkende im Projekt verfügbar wird aber nicht völlig offen publiziert. Allgemein ist das Projekt für jeden Interessierten zugänglich und wir freuen uns immer über neue Ideen.
Bei Interesse einfach melden.Freundliche Grüße,
ThreadDB
-
Zumindest ich würde mir sowas als closed-source sicher nicht antun. Grad auch mit den ganzen riesigen Mengen an Projekten und Infrastrukturcode, die Google, Facebook, Microsoft usw. als Open Source freigegeben haben, sehe ich gar keinen mehr Grund, mir so eine kleine Bibliothek anzuschauen oder zu verwenden, von der ich keinen Code habe.
Allein schon das ausliefern als Dll ist problematisch... Was ist, wenn ich nicht NOCH eine Dll will, sondern das lieber statisch linken würde? Und dann würden evtl. auch mehr Optimierungen greifen, weil ich dann whole program optimization aktivieren könnte.
-
Hallo Mechanics,
vorab herzlichen Dank für Deine ausführliche Antwort. Die Verfügbarkeit des Quelltextes hat sicher Vorteile.
Die Entscheidung für eine Bereitstellung als dll ist aus zwei Gründen gefallen. Zum einen die bessere Kontrolle über das Build System. Hier hat sich gezeigt dass es zwischen den C++ Compilern merkantile Unterschiede gibt. Das aktuelle Spektrum der Tools ist sehr weit gefächert - MS, gnu Varianten, clang, Borland. Sicherzustellen das der Code für jeden Compiler geeignet und effizient ist, ist mit erheblichem Aufwand verbunden.Lässt man dies ausser Acht führt dies u U. benutzerseitig schnell zu Frustration. Als weiteren Punkt ist anzumerken, dass so das Umfeld in dem die SW verwendet wird besser nachvollziehbar ist.
Generell besteht aber immer die Möglichkeit am Einsatz Interessierten, Zugang zu den Sourcen zu ermöglichen.Mit freundlichen Grüßen,
ThreadDB
-
@threaddb Niemand beisst euch den Kopf ab, wenn ihr im Readme sagt, dass es mit Buildsystem X und Compiler Y gebaut wird und dafür optimiert ist. Das ist sogar recht üblich. Wenn es dann Open-Source ist und zum Beispiel auch auf GitLab oder GitHub vorhanden, könnte man es forken und Merge/Pull-Request machen, um andere Compiler zu unterstützen. Also andere könnten helfen, die Bibliothek zu optimieren. Oder die Leute könnten es einfach für ihr Projekt anpassen. Ihr habt es hier nicht mit Endbenutzern zu tun sondern mit anderen Entwicklern.
So wie es jetzt ist, wirkt das für mich nicht sehr vertrauenswürdig.
