Map Key == Klassenmember des Objekt??

ja genau

//das erste mal
//Es wird ein foo objekt er zeugt, das foo objekt enthält eine list der ein eleme hinzugefügt wird
mymap[5].func(elem1);

//Das zweite mal
//Es wird dem vorhanden foo objekt mit der ID 5 ein elem in der liste angefügt.
mymap[5].func(elem2);

das ist meien vorhaben...

P.S. :Ich könnte natürlich einen vector anlegen mit X foo objekten ,und über den indnex drauf zugreifen... aber wenn nich nur einige index benötige und nicht alle also vll. nur 4 von 100 muss ich ja nich jedes mal 100 objekte anlegen. Wäre natürlich die zweite alternative wenn das mit der map nich klappt

bladerunner10

Das geht wohl so mit der std::map nicht (direkt).
Mit der std::map wird bei foomap[5] ein Default-Konstruiertes foo-Objekt in die map mit dem Key 5 eingefügt. Das heißt aber nicht, daß das foo-Objekt mit 5 initialisert wird.
Für sowas müßtest du wohl die std::map in eine eigene Klass tun, die im opertator[] prüft, ob das entsprechende Objekt existiert oder nicht, ggf. eins anlegt und das zurückliefert.

Ungefähr so:

// ungetestest als Pseudo-Code zu verstehen!

foo& mymap::operator[](int key) 
{
    std::map<int,foo>::iterator it = thefoomap.find(key);
    if(it == thefoomap.end())  // foo-Object nicht da
    {
        thefoomap.insert(std::make_pair(int, foo(int));
    }
    return thefoomap[key];
}

asc

bladerunner10 schrieb:

Für sowas müßtest du wohl die std::map in eine eigene Klass tun, die im opertator[] prüft, ob das entsprechende Objekt existiert oder nicht, ggf. eins anlegt und das zurückliefert.

Das wird sehr umständlich werden, wenn der OP nicht alle Funktionen der map durchschleift. Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Ist es wirklich so schlimm bei Sonderfällen auf eine separate Funktion umzusteigen? Sprich statt den Operator [] eine Funktion zu verwenden?

cu André

bladerunner10

[quote="asc"]

bladerunner10 schrieb:

...
Das wird sehr umständlich werden, wenn der OP nicht alle Funktionen der map durchschleift. Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Warum nicht ?

asc schrieb:

Ist es wirklich so schlimm bei Sonderfällen auf eine separate Funktion umzusteigen? Sprich statt den Operator [] eine Funktion zu verwenden?
cu André

Kommt natürlich auf den konkreten Anwendungsfall an, würde ich aber wahrscheinlich auch eher so machen.

asc

bladerunner10 schrieb:

asc schrieb:

...
Das wird sehr umständlich werden, wenn der OP nicht alle Funktionen der map durchschleift. Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Warum nicht ?

Die Standardcontainer haben z.B. keinen virtuellen Destruktor was sie in der Regel für eine Ableitung disqualifiziert.

bladerunner10 schrieb:

asc schrieb:

Ist es wirklich so schlimm bei Sonderfällen auf eine separate Funktion umzusteigen? Sprich statt den Operator [] eine Funktion zu verwenden?
cu André

Kommt natürlich auf den konkreten Anwendungsfall an, würde ich aber wahrscheinlich auch eher so machen.

Es kommt eben nicht nur auf den Anwendungsfall, sondern auch auf die vorliegenden Rahmenbedingungen an. Wenn eine Klasse keine Ableitung vorsieht, sollte man auch tunlichst vermeiden davon abzuleiten. Und einen Proxy für eine std::map zu schreiben ist zwar möglich, nicht desto trotz aber umständlicher als auf eine Funktion auszuweichen.

cu André

bladerunner10

asc schrieb:

bladerunner10 schrieb:

asc schrieb:

...
Das wird sehr umständlich werden, wenn der OP nicht alle Funktionen der map durchschleift. Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Warum nicht ?

Die Standardcontainer haben z.B. keinen virtuellen Destruktor was sie in der Regel für eine Ableitung disqualifiziert.

Ich würde sagen: Was sie für eine polymorphe Benutzung disqualifiziert.

Es spricht absolut nichts gegen sowas:

class MyIntVector : public std::vector<int> {
   // c'tor, etc.
};

MyIntVector  miv;
miv.push_back(42);

Auch wenn das zugegebenermaßen nicht das schönste Design ist.

asc

bladerunner10 schrieb:

Ich würde sagen: Was sie für eine polymorphe Benutzung disqualifiziert.

Und nicht garantiert das der Destruktor vom Standardcontainer aufgerufen wird.
Na, ob das Sinn macht?

Siehe auch diesen Thread.

cu André

bladerunner10

asc schrieb:

bladerunner10 schrieb:

Ich würde sagen: Was sie für eine polymorphe Benutzung disqualifiziert.

Und nicht garantiert das der Destruktor vom Standardcontainer aufgerufen wird.

Diesen Satz verstehe ich nicht.

Fakt ist doch, daß man von std:: Containern ableiten kann und keine Probleme
bekommt, solange man nicht über den Basisklassen Zeiger delete't. Ob das Sinnvoll
ist, hängt vom Anwendungsfall ab.

Das Thema ist jetzt für mich erledigt.

asc

bladerunner10 schrieb:

Fakt ist doch, daß man von std:: Containern ableiten kann und keine Probleme bekommt, solange man nicht über den Basisklassen Zeiger delete't.

Man sollte niemals unnötige Fehlerquellen provozieren.

asc schrieb:

Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Irgendwie finde ich nicht die Stelle an der bladerunner Vererbung verwendet hat

bladerunner10

bladerunner10 schrieb:

...
Es spricht absolut nichts gegen sowas:
class MyIntVector : public std::vector<int> {
   // c'tor, etc.
};
...

Das war aber erst nach diesem Satz

asc schrieb:

Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Dravere

KasF schrieb:

asc schrieb:

Weil von den Standardkontainern abzuleiten ist nicht vorgesehen!

Irgendwie finde ich nicht die Stelle an der bladerunner Vererbung verwendet hat

Du hättest auch den ganzen Abschnitt lesen sollen. Bladerunner schlägt vor den Container in eine eigene Klasse zu setzen und den Operator[] geprüft anzubieten.

Asc macht dann darauf aufmerksam, dass die Sache umständlich wird, da man am Ende alle Funktionalitäten der Map wrappen müsste. Und weil viele dann wohl als nächstes denken: "ICH KANN JA ABLEITEN", hat er wohl noch diesen Satz dazugefügt.

Und ich denke es war gar nicht so dumm, dass er diesen dazugefügt hat, nicht?

Grüssli

Ahh *BLINK*, danke Dravere