Pointer2Iterator?
-
Nein, da gibt es leider keine Möglichkeit, obwohl es afaics einfach zu implementieren wäre... Am besten ist es dann vermutlich, konsequent list::iterators direkt zu verwenden, soweit es geht
-
Shade Of Mine schrieb:
Nimm find:
list<int>::iterator it=find(liste.begin(), liste.end(), *zeiger); if(it!=liste.end()) liste.erase(it);Dort finden sich auch Elemente die zwar denselben Wert, aber eine andere Adresse haben.
-
DrGreenthumb schrieb:
Dort finden sich auch Elemente die zwar denselben Wert, aber eine andere Adresse haben.
Ich bin mal davon ausgegangen, dass die der Status des Objektes und nicht die Adresse wichtig ist.
Aber du hast recht, wenn man davon nicht ausgeht wird es komplizierter - denn dann müsste man sich ein Predikat schreiben, welches die Adressen vergleicht.
Mhm, OK - auch nicht viel schwerer.
-
Shade Of Mine schrieb:
Aber du hast recht, wenn man davon nicht ausgeht wird es komplizierter - denn dann müsste man sich ein Predikat schreiben, welches die Adressen vergleicht.
oder eine 'komplizierte' for-schleife
-
Jetzt versteh ich so langsam was er machen wollte
Für was braucht man aber für das suchen des Zeigers ein Predikat ?
Zeiger sollten sich doch generell mit == prüfen lassen
-
Nein, wenn er in der Liste keine Zeiger speichert, müsste er überprüfen ob die Adresse des Elements gleich der gesuchten Adresse ist, d.h. er sucht nach einem Iterator iter, für den gilt: &*iter == pMeinElement.
Eigentlich wirklich schade, dass es keine ptr2iter-Methode gibt, sollte ja nicht schwer umzusetzen sein?
-
Bin mal wieder schwer von Begriff :o(
Wenn die Aussage stimmt:
Er hat list<T> und möchte mit hilfe von T* suchen ?
dann hab ich es nun nach stunden geschnallt O
-
Er hat list<T> und möchte mit hilfe von T* suchen ?
Frage mich auch grad !
Ich mein, wie kommt er denn zu dem zeiger ?
er bekommt doch normal immer schoen kopien von seinem object ... es sei denn, er hat den Zeiger selbst mit &*iter mal ermittelt ! Zu welchen Zweck ?
Das ganze klingt mir irgendwie hochgradig unsicher .... (lass mal nen sortierallgorythmus ueber die liste laufen !
)
Vom design her sollte das wesentlich besser zu loesen sein ...ich vermute eher, er hat sich etwas umstaendlich ausgedrueckt und hat doch ne list<T *> ... ???
Ciao ...
-
Von mir aus kann er auch eine Referenz speichern:
std::list<int> list; list.push_back(5); int& i = list.back();Die Regeln, wie lange diese Referenz gültig ist, sind im Standard genau festgelegt. Und wenn er das Element finden will, auf das die Referenz verweist, kommt er um einen Vergleich "&i == &*iter" nicht herum.
Und wenn man jetzt noch die Referenz durch einen Zeiger ersetzt...
-
Ja, mir ist aufgefallen, dass die Idee einem Designfehler zugrunde liegt
:p 
sry
Glamdring
-
Die Regeln, wie lange diese Referenz gültig ist, sind im Standard genau festgelegt
Richtig, aber er schraenkt die verwendung seines containers damit ein ! Fuer welchen preis ? Ich meine ne Containerklasse mit "Vorsicht bitte nie Elemente umkopieren sortieren etc. !!!" im Header find ich ned schoen :p
Wenn ich STL conatiner in die Finger bekomme, steze ich halt voraus, das ich ihn wie nen stl container benutzen kann.Wo ichs mir vielleicht gefallen lassen wuerd, waer wenn der container const waer ! :p Nur braucht man dann noch nen STL container ??? :p
@Glamdrink
Ich mein, gangbar ist der weg schon, ist nur ne frage des preises ... man vermeided eine zusaetzliche schicht von dynamisch angelegten Pointern, der Preis dafuer ist ein "ruehr mich nicht an" container :p und ein bisserl unuebersichtlichkeit und ein bisserl abweichung von der "Normalen" benutzung der STL.
Also wenn Dir 100% sicher bist, das niemand anders an deinen container rankommt, dein project niemals nie von jemand anderes spaeter gepflegt werden muss, dann mach es so !
Andernfalls zahle besser die dynamischen pointer und bekomm dafuer nen wesentlich flexiebleres und mehr intuitiv wartbareres System.
Oder schreib halt selber nen container, der dir genau das bietet was du willst wo die anderen nutzer halt nicht STL gerechtes verhalten dann erwarten. STL ist nicht immer die allgemeingueltige Loesung !Ciao ...
-
Es steht ja nirgends, über welchen Zeitraum und in welchem Kontext er den Zeiger auf das Element benutzen will. Von daher sind Zeiger auf Elemente genauso gefährlich oder ungefährlich wie Iteratoren...
Wenn ich mir dein Posting so durchlese, glaube ich, wir denken einfach automatisch an völlig verschiedene Situationen.
-
Naja, ich gehe davon aus, dass er den Pointer/Referenz ueber den scope eines funktionsaufrufes hinaus verwenden will ...
Warum sollt er sonst den pointer/referenz in nen Iterator zurueckverwandeln wollen, wenn er ihn doch am anfang schon ueber nen iterator erzeugt hat (oder beim einfuegen nen Iterator soweiso bekommen tut ) ?in einer funktion, wo man selbst die "unversehrtheit" des containers sicherstellt, keine frage, koennt man es so machen ...
Ciao ...