zuordnung konfigurationsdaten <-> objekt

[MrIni]

Hallo.

Ihr kennt doch sicher das Problem, dass man bei sehr vielen Programmen Konfigurationsdaten in Dateien speichern will, um davon laden und dazu speichern zu können.
Im Prinzip muss jede Klasse, die dort etwas ablegen will nur Methoden bereitstellen, um dareinzuschreiben und davon zu lesen.
Dazu bietet sich z.B. ein einfaches .ini format an.

Allerdings ist mein Problem folgendes:
Wie kann ich einzelne Objekten den jeweiligen Konfigurationsdaten zuordnen?

Mein Erster Ansatz ist folgender:
Jedes Objekt hat eine id zur Zuordnung, das hat bei mir auch schon mal funktioniert, allerdings sehe ich da vor allem den nachteil, dass es tierisch nervt, wenn man die id's im quelltext hardcodet (so hab ich das bisher gemacht).

Ein Beispiel zu diesem vorgehen:

IniFile ini("config.ini");
//die zahlen sind IDs, ich nehme jetzt an, dass die buttonklasse ids speichern kann
Button b1(1);
Button b2(2);
b1.LoadFromFile(iniFile);
b2.LoadFromFile(iniFile);

Die ini datei sieht dann ungefähr so aus:

[1]
width = 5
height = 10
[2]
width = 20
height = 3

Eine Idee wäre dann, in Konstruktoren eine statische variable hochzuzählen und dadurch
ids zu vergeben, aber dann müsste man zwischen den typen der objekte unterscheiden und was viel schlimmer ist: Das funktioniert dann nur, wenn man die Objekte immer in der selben reihenfolge erstellt...

Habt ihr dazu Ideen, wie das besser geht?

[,.-,.-]

Scriptsprache benutzen.

[MrIni]

,.-,.- schrieb:

Scriptsprache benutzen.

Hm, klingt ziemlich aufwändig, allein das einrichten erstmal das das geht (ich denke mal du meinst c++ mit scriptsprache kombinieren und nicht script standalone).
Und kannst du bitte mal ein wenig ausführen, inwiefern das hilft?

Auch für weitere Vorschläge bin ich dankbar.

[Nexus]

Wahrscheinlich würde sich eine etwas dynamischere Vorgehensweise bewähren. Du erstellst also nicht für jeden Button ein einzelnes Objekt, sondern eine

std::map<ID, Button>

wobei ID unter Anderem ein Integer oder ein String sein kann. Letzteres ist benutzerfreundlicher, da du gleich eine Semantik einbringen kannst ("close-button").

[MrIni]

Gute idee, auf jeden fall schonmal eine Besserung.
Allerdings will ich ja nicht nur buttons haben^^
Also brauch ich entweder einige maps für die unterklassen oder eine die (abstrakte) basisklassen mappt.

Falls jemand noch nen Vorschlag hat, bitte her damit

[EOutOfResources]

Wie Nexus, jedoch mit Zeigern auf Buttons (oder deren Parent).

[Nexus]

MrIni schrieb:

Also brauch ich entweder einige maps für die unterklassen oder eine die (abstrakte) basisklassen mappt.

Welche der beiden Varianten du nimmst, hängt davon ab, wie viel Abstraktion du betreiben willst. Kannst du alles schön polymorph erledigen (Buttons verhalten sich automatisch anders als CheckBoxes), würde ich eine abstrakte Basisklasse nehmen.

Aber wenn du anschliessend doch immer am Fälle unterscheiden bist und mit dynamic_cast prüfst, ob du den richtigen Typ hast, greifst du lieber gleich zur statischen Typsicherheit. Also pro GUI-Klasse eine Map.