class Y
{
public:
	Y(const std::string &key) :
		_key(key)
	{
	}

	void set_some_value(int a)
	{
		_a = a;
	}

private:
	std::string _key;
	int _a;
};

class X
{
public:
	Y &append_entry(const std::string &key)
	{
		Y entry(key);
		_data[key] = Y;

		return Y;
	}

private:
	std::map<std::string, Y> _data;
};

int main(int argc, char *argv[])
{
	X test;
	Y entry = test.append_entry("test");
	entry.set_some_value(200);

	return 0;
}

Vielen Dank!

Du gibst eine Referenz auf ein lokales Stackobjekt zurück. Das erzeugt undefiniertes Verhalten sobald du versuchst mit der Referenz zu arbeiten. Denn lokale Objekte werden am Scopeende zerstört.

Allerdings dürfte ersteinmal nichts passieren, bis du versuchst mit der Referenz auf nicht-statische Membervariablen zuzugreifen (oder auf Funktionen, die auf nicht-statische Membervariablen zugreifen).

Warum verwendest du die Map nicht einfach direkt? X und Y sind hier ja schon recht sinnfrei ...

Warum verwendest du die Map nicht einfach direkt? X und Y sind hier ja schon recht sinnfrei ...

Das X und Y sinnfrei sind, weiß ich auch. Das ist ein aufs minimale runtergebrochene Beispiel.

hustbaer schrieb:

Es ist auch totaler Käse, weil nichtmal die Syntax passt.
Y ist ne Klasse und keine Instanz, also kann man nicht einfach = Y oder return Y sagen.

Das ist korrekt. Habe mich in der Eile vertippt - sorry.

Wie arbeite ich denn dann richtig mit Referenzen und map-Entries? Oder geht das gar nicht?

In Kurzfassung:

Klasse &get_entry(std::string key)
{
    map_type::iterator it = _data.find(key);

    if (it != _data.end())
    {
        return it->second;
    }

    return _null_value;
}

Definiert oder ist es der gleiche Fall wie vorher (Referenz auf funktionslokale Variable)?

In Kurzfassung:

Klasse &get_entry(std::string key)//Das ist also keine Memberfunktion? _data ist global deklariert?
{
    map_type::iterator it = _data.find(key);
    
    if (it != _data.end())
    {
        return it->second;
    }
    
    return _null_value;
}

Solange _null_value global oder in der Klasse (als static und mit const -qualifier, damit nicht etwas doofes passiert wie du holst die Referenz und behälst sie bis nachdem das Objekt mit der map zerstört wurde) deklariert wurde, ist alles im Lot... wenn du das ganze auch wie oben deklarierst, kannst du (wie bei find() ) mit einer (Un)gleichung prüfen, ob ein Eintrag vorliegt.

In Kurzfassung:

Klasse &get_entry(std::string key)
{
    map_type::iterator it = _data.find(key);
    
    if (it != _data.end())
    {
        return it->second;
    }
    
    return _null_value;
}

Das mit dem _null_value gefällt mir da zwar gar nicht, aber es ist okay, also keine Objektlebenszeit-Fehler.

Alternative1: Ausnahme werfen, falls Schlüssel nicht auffindbar

Alternative2: Objekt Default-konstruieren lassen, falls Schlüssel nicht auffindbar:

Klasse& get_entry(std::string const& key)
{
    return _data[key];
}

Alternative2: Objekt Default-konstruieren lassen, falls Schlüssel nicht auffindbar:

Wobei sich dann bald die Frage stellt, was die Klasse überhaupt soll. Kann man bald std::map direkt verwenden.

_null_value macht dahingehend Sinn, da folgendes möglich sein soll:

Block &block = _root.GetBlock("hallo").GetBlock("test");

if (!block.IsValid())
{
    // _null_value;
}

int a;
block.GetValue("a", a);

Ergo: _null_value ist ein leerer Block, welcher ein valid -Flag auf false setzt.

Die erfüllen einen ähnlichen Zweck, nur auf etwas andere Art: man soll doc->Get("foo")->Get("bar") machen können ohne dass es fetzt, selbst wenn es "foo" schon nicht gibt.

Dummerweise ist die Online-Doku grad offline, sonst hätte ich dir die Seite verlinkt.

Auf externe Libs habe ich nicht so viel Lust...

Btw: _null_value ist im globalen Scope ein reservierter Name.

Genau das kann man mit meiner Lösung doch auch machen. Oder ist sie schlecht, um so etwas realisieren? Ich finde es eigentlich optimal so (mit meinen eher beschränkten Kenntnissen über die STL).

Ich hab's nur erwähnt weil ich dachte vielleicht willst du dir ansehen wie das in einem anderen Projekt gelöst wurde.
Und ich persönlich finde die "Handle" Lösung auch sauberer.
Weil man sich dadurch etwas eine seltsam anmutende Eigenheit im primären Interface spart.

Auf externe Libs habe ich nicht so viel Lust...

?
Hat ja auch keiner vorgeschlagen...