Überladen von []/=

Alles bis auf das Deklarieren geht nicht.

30 [...] 'class MyProxy<std::string, t>' has no member named 'foo'

otze

ist ja auch klar, dass es nicht geht. die konvertierungsoperatoren treten nur in kraft, wenn der compiler weis, dass er konvertieren muss. So schaut er nur, ob MyProxy eine variable foo hat.

also konvertierst du entweder von hand mithilfe eines casts, doer lässt dir was einfallen.

möglichkeit 0:
einfach casten:

static_cast<t>(test2["foo"]).foo

möglichkeit 1:
eine get methode einbauen. dann sieht es so aus:

test2["foo"].get().foo

möglichkeit 2:
überladen des op->

test2["foo"]->foo

otze schrieb:

also konvertierst du entweder von hand mithilfe eines casts, doer lässt dir was einfallen.

Also das "lässt dir was einfallen" wollte ich eigentlich euch überlassen

möglichkeit 0:
einfach casten:
static_cast<t>(test2["foo"]).foo

Funktioniert, macht den Code aber nicht grade schöner.

möglichkeit 1:
eine get methode einbauen. dann sieht es so aus:
test2["foo"].get().foo
möglichkeit 2:
überladen des op->
test2["foo"]->foo

Das geht für meinen ersten Fall

test["foo"]["bar"] = "test";

aber nicht, oder?

camper

otze schrieb:

du musst ja nicht interna des proxys zurückgeben, sondern interna des objekts, vor das sich der proxy vorschaltet ;).

womit der proxy sich selbst ausschaltet - ich dachte der zweck des proxies wäre gerade, den zugriff auf diese interna zu maskieren.
original:

struct X
{
    // ...
    int& operator[](size_t i) { return data[i]; }
};
void foo(int&)
{
// ...
}
void bar()
{
   X x;
   foo(x[1]);
}

jetzt mit proxy:

struct X
{
    struct Proxy
    {
        // ...
        int& ref_;
        operator int&() { return ref_; }
    };
    // ...
    Proxy operator[](size_t i) { return Proxy(data[i]); }
};
void foo(int&)
{
// ...
}
void bar()
{
   X x;
   foo(x[1]);
}

ups, das kompiliert ja immer noch... und dabei wollten wir doch einen proxy damit wir bei veränderungen noch ein bisschen extra arbeit erledigen können.

Hat jetzt keiner eine Lösung für mein Problem? Mit normalen Maps funktioniert es ja schließlich auch, also muss es doch wohl eine Möglichkeit geben eine Map nachzubauen (mit kleinen Änderungen) die das genauso funktioniert.

otze

normale maps benutzen keinen proxy. normale maps geben das objekt ansich zurück. Und da der Proxy nicht das Objekt selber ist, kannst du auf ihm nicht die methodend es Objektes aufrufen. du müsstest dir dann schonmal was basteln, was dir das objekt selber gibt(also zb der op->). Die einzige lösung wär, beim proxy den operator. zu überladen, aber das _darfst_ du nicht. Das sieht der Standard leider nicht vor.

otze schrieb:

normale maps benutzen keinen proxy. normale maps geben das objekt ansich zurück.[...]Die einzige lösung wär, beim proxy den operator. zu überladen, aber das _darfst_ du nicht. Das sieht der Standard leider nicht vor.

Und wie konkret machen die maps das bzw. warum kann ich das nicht auch so machen?

du müsstest dir dann schonmal was basteln, was dir das objekt selber gibt(also zb der op->).

Das kann ich mal ausprobieren.

otze

Floele schrieb:

otze schrieb:

normale maps benutzen keinen proxy. normale maps geben das objekt ansich zurück.[...]Die einzige lösung wär, beim proxy den operator. zu überladen, aber das _darfst_ du nicht. Das sieht der Standard leider nicht vor.

Und wie konkret machen die maps das bzw. warum kann ich das nicht auch so machen?

die amchen das garnicht. die geben nur ne referenz auf das objekt zurück, welches gesucht wird.

Vielleicht hilft es ja wenn wir das ganze von hinten angehen, vom Ziel her. Mein Ziel ist es nämlich (hauptsächlich jedenfalls) eine unsortierte Map zu erstellen. Mit Google habe ich da nichts passendes gefunden. Gibt es nicht irgendeine Möglichkeit sowas zu erstellen?

CStoll

unsortierte Map? reicht ein vector<pair<k,v> > (oder list<pair>) für deine Zwecke schon aus?

Wenn ich wie bei einer map["a"]["b"] darauf zugreifen kann schon, aber das geht nicht, oder?

CStoll

Das müsstest du dir selber schreiben. Kannst du eventuell mal detaillierter beschreiben, was du vorhast?

Ja, ganz einfach. Ich will eine Map, die genauso funktioniert wie die richtige Map (also auch verschachtelbar, beliebige Typen als Key/Value etc.) mit dem einzigsten Unterschied dass sie unsortiert ist. Das heißt dass das was zuerst in die Map reinkommt soll auch zuerst wieder rauskommen (FIFO wird das glaube ich genannt).

CStoll

Wie wär's mit einer "list<pair<K,T> >" oder "deque<pair<K,T> >" für diesen Zweck? (verwende jeweils push_back() zum anfügen und front()/pop_front(), um das älteste Element abzufragen und rauszuschmeißen)

camper

boost::multi_index_container

CStoll schrieb:

Wie wär's mit einer "list<pair<K,T> >" oder "deque<pair<K,T> >" für diesen Zweck? (verwende jeweils push_back() zum anfügen und front()/pop_front(), um das älteste Element abzufragen und rauszuschmeißen)

Und wie kann ich dann zum Beispiel ein Element (aus der Mitte) abfragen oder ändern?

boost::multi_index_container

Ne, der Aufwand lohnt sich nicht. Wahrscheinlich würde ich es sowieso nicht schaffen Boost einzubinden.

camper

Floele schrieb:

Und wie kann ich dann zum Beispiel ein Element (aus der Mitte) abfragen oder ändern?

std::find, und dann machst du was mit dem iterator

Ist das nicht zu langsam?

finix

camper schrieb:

Floele schrieb:

Und wie kann ich dann zum Beispiel ein Element (aus der Mitte) abfragen oder ändern?

std::find, und dann machst du was mit dem iterator

Wohl eher std::find_if!?

Floele schrieb:

Ist das nicht zu langsam?

Zu langsam wofür?
Was stellst du hauptsächlich mit dem Container an?

Naja, ich speichere Daten darin, lese sie aus und ändere sie. Wieviele ist abhängig von der Größe der Ausgangsdatei. Mit "zu langsam" meine ich ob es gut ist das so zu machen, ich könnte mir vorstellen dass das mit normalen Maps dann um ein vielfaches schneller ist als immer wieder nach dem richtigen Key zu suchen.