Hallo liebe Leser,
ich habe vor einigen Minuten, naja sagen wir mal vor ca. einer Stunde, ein kleines Update für gINI gebastelt.
Ab jetzt liegt gINI in einem eigenen Namensraum.
Dieser heißt passend auch gINI.
Sowohl die main.cpp als auch alle Dateien würden angepasst.
Auch habe ich mir gedankten um gINI gemacht.
Ich war vor einigen Tagen im Büro und konnte mit meinem Kollegen den Hinweis bekommen, dass ich gINI per lib o.ä. verteilen sollte.
An sich ist das auch ne feine sache.
Die Entwickler müssten nur ihre eignen libs anpassen und die neue Version binden.
Auch würde durch die Auslagerung in einer .dll/.so der RAM nicht extra belastet werden, da die Codes im Programm mit in den RAM fließen würden.
Soweit so gut.
Das dumme an der Sache wäre aber erstmal, dass ich doppelten Aufwand hätte, da ich immer eine .dll und eine .so pflegen müsste.
Da auch die Codes noch zu klein sind, ist es auch noch nicht sinnvoll eine .dll/.so anzulegen.
Solange werde ich gINI erstmal noch als Code libs verteilen.
Danach werde ich aber eine .dll/.so erstellen und verteilen.
Ansonsten habe ich an gINI nicht mehr viel gemacht.
Ich muss auch noch planen wie ich gINI zu einem Multitalent beim parsen machen kann.
Den einer seits soll gINI einfache Win32 ini Dateien einlesen und verarbeiten können aber anderer Seits auch andere ini Dateitypen unterstützen.
Somit sollte mit einer größeren Anzahl von ini Dateitypen auch der Nutzen für Anwender und Entwickler größer sein.
Desweiteren hat mich mein Kollege auch aufgeklärt, warum .ini unter Windows gegen XML getauscht wurde.
Das große Problem ist nur, dass die Art des Zeichensatzes nicht vermerkt wurde.
Dies könnte ich aber mit einem Spezialeintrag umgehen.
Ob dies aber eine optimale Lösung ist, wird sich wohl erstmal zeigen müssen.
Mit freundlichen Grüßen
T-Virus
Keine Kommentare:
Kommentar veröffentlichen