Datenstruktur für .ini Files

[SirLant]

Eigentlich hab ich nur eine Frage dazu und zwar was haltet ihr von folgender Form zur Speicherung des Inhaltes einer .ini Datei

map<String, list<pair<String,String> > >

?

So könnte man über die Map bequem auf die einzelnen Blöcke zugreifen (den Namen kennt man ja im regelfall) und erhält in einer Liste alle Variablen(?) und deren Werte als Paar.

Die Liste hab ich gewählt, da man ja meist alle Elemente durchgehen muss und es keine feste Reihenfolge gibt, wodurch nen Vektor keinen Sinn macht, aber man weiß beim einlesen auch nicht wieviele Zeilen die Blöcke groß sind und kann daher auch nicht genug Elemente im voraus reservieren. Wie man mit den beiden Werten einer Zeile am besten umgeht wusst ich nicht so genau und dachte mir, dass nen pair da vllt. ne ganz gute Lösung ist.

Soweit zu meinen Überlegungen, jetzt würd ich gern hören, ob ihr die Lösung gut findet, oder es anderst machen würdet.

[volkard]

was spricht gegen map<string,map<string,string> >?

[SirLant]

Das hatte ich auch zuerst im Kopf, aber was wenn man die Variablennamen nicht kennt?

[volkard]

SirLant schrieb:

Das hatte ich auch zuerst im Kopf, aber was wenn man die Variablennamen nicht kennt?

kann man durch ne map nicht auch mit nem iterator durchlaufen, so wie bei ner liste? wenn ich mich recht erinnere, gibt *iter dann auch ein pair<string,string> zurück.

[Walli]

Ja kann man (falls das jetzt keine rhetorische Frage war ).

[evilissimo]

SirLant:

Ich selbst hab mir auch mal so eine Klasse geschrieben die INI-Files einliest und schreibt und hab auch als Typ " std::map< std::string , std::map < std::string , std::string > > " benutzt.

Das klappt wunderbar und du kannst ja auf die Werte per Key zugreifen.

z.b.

string value1 = ini_map["section1"]["Key1"];

MfG eViLiSSiMo

[SirLant]

Musste mich oben leider kurz fassen, da ich grad abgeholt wurde. Dachte da, dass ne Map eigentlich eher schlecht ist, da ich das ganze ja in erster Linie für mich mache und ich die Namen nicht kenne, da sie wohl im sequentiellen Zugriff wohl langsamer sein wird.
Aber nach genauerer Überlegung bin ich zu dem Entschluss gekommen, dass das ja gar nicht der Fall ist, da ne Map ja von der Struktur genauso Element für Element durchgegangen werden kann.

Dann werd ich ne map<string, map<string, string> > nehmen

[Vellas]

Hi!

Habe eine Bibliothek geschrieben, die wir für ne C-Seminaraufgabe schreiben sollten, also ich verwende folgendes als ich die Implementierung nach C++ konvertiert habe:
map<string, map<string, string> >;
Grund:
Schlüssel ist ein Chapter, dieser enthält wederum mehrere Schlüsselwertpaare, welche ich wieder in einer map Speicher.

EDIT: Oh, ich hatte mich verlesen, der Vorschlag war ja schon da...

Code-Hacker

[Vellas]

del

[SirLant]

Bin grad irgendwie zu blöd den map iterator zu benutzen, der muss für ne map<string, map<string,string> > doch so aussehen map::iterator<string, map<string, string> > oder?

[DrGreenthumb]

map<string, map<string,string> >::iterator

[SirLant]

Bekomme auch so nen Fehler

e:\Sources\CPP\HelloWorld\HelloWorld.cpp(16): error C2440: 'Initialisierung': 'std::map<_Kty,_Ty>' kann nicht in 'std::_Tree<_Traits>::iterator' konvertiert werden
with
[
_Kty=std::string,
_Ty=std::mapstd::string,std::string
]
and
[
_Traits=std::_Tmap_traits<std::string,std::mapstd::string,std::string,std::lessstd::string,std::allocator<std::pair<const std::string,std::mapstd::string,std::string>>,false>
]

[virtuell Realisticer]

Wo bekommst du diesen Fehler? Wie sollen wir was dazu sagen, wenn du nicht das
Codestueck zeigst?

mfg
v R

[SirLant]

Na in der Initialisierung des Iterators, so wie es DrGreen oben geschrieben hat.

std::map<std::string,std::map<std::string, std::string> >::iterator foo2 = foo1;

foo1 ist std::map<std::string,std::map<std::string, std::string> > foo1; (da meckert er auch nicht und die Map funktioniert auch)

[virtuell Realisticer]

SirLant schrieb:

Na in der Initialisierung des Iterators, so wie es DrGreen oben geschrieben hat.

std::map<std::string,std::map<std::string, std::string> >::iterator foo2 = foo1;

foo1 ist std::map<std::string,std::map<std::string, std::string> > foo1; (da meckert er auch nicht und die Map funktioniert auch)

foo1 ist aber kein iterator. Einen solchen musst du aber liefern, z. B. so:

std::map<std::string,std::map<std::string, std::string> >::iterator foo2 = foo1.begin();

mfg
v R

[SirLant]

Danke, hätte wohl schon früher mal etwas mehr mit iteratoren arbeiten sollen, aber das werd ich jetzt mal nachholen

[SirLant]

Nach etwas tüfteln hab ich jetzt folgendes um die Map auszugeben und es scheint richtig zu sein, aber geht das nicht auch einfacher, kommt mir etwas kompliziert vor

Typedefs werd ich natürlich benutzen, aber das war ja nur zu testzwecken

for (std::map<std::string,std::map<std::string,std::string> >::iterator foo2 = foo1.begin(); foo2 != foo1.end(); ++foo2)
	{
		cout << foo2->first << endl;
		for (std::map<std::string,std::string>::iterator foo3 = foo2->second.begin (); foo3 != foo2->second.end(); ++foo3)
			cout << "\t" << foo3->second << endl;
		cout << endl << endl;

	}

[DEvent]

und was is daran so kopliziert ?

[fsljkhdykvb]

map<string, map<string, string> >::iterator iter;

usw...
Wie war das nochmal mit dem selbst nachdenken??

[SirLant]

fsljkhdykvb schrieb:

map<string, map<string, string> >::iterator iter;

usw...
Wie war das nochmal mit dem selbst nachdenken??

Das hat doch DrGreen bereits gesagt und wie du siehst hab ich ja alles bereits zum laufen bekommen.

DEvent ich wollte wissen ob es auch "einfacher" bzw. kürzer geht, oder ob das der normale Weg ist, so wie ich es jetzt habe.

[virtuell Realisticer]

SirLant schrieb:

fsljkhdykvb schrieb:

map<string, map<string, string> >::iterator iter;

usw...
Wie war das nochmal mit dem selbst nachdenken??

Das hat doch DrGreen bereits gesagt und wie du siehst hab ich ja alles bereits zum laufen bekommen.

DEvent ich wollte wissen ob es auch "einfacher" bzw. kürzer geht, oder ob das der normale Weg ist, so wie ich es jetzt habe.

Wie du bereits angedeutet hast, geht man den langen Schreibsessions aus dem Weg,
indem man hier mit typedef's arbeitet.

Kuerzer geht es ansonsten nicht.

mfg
v R