Iterator als eindeutiges Element zurückgeben?



  • In meiner map ist jedes Element durch einen iterator eindeutig definiert. Diesen Iterator muss ich über ein void* zurückgeben. Casten klappt leider nicht.
    Wie geht das?



  • Diesen Iterator muss ich über ein void* zurückgeben

    Aehm, wie meinst du das ?

    void * myfindfunction()
    {
    void * p_ret = NULL;
    std::map<int,CMyClass>::iterator it = mymap.find(3);
    if(it != mymap.end())
    {
    p_ret = new std::map<int,CMyClass>::iterator(it);
    }
    return p_ret;
    }
    

    geht nicht ?
    Aber irgendwie designmaessig ... iterator in void * ... kann ich mich ned anfreunden. Gibts da ned nen besseren weg ?
    Iteratoren ausserhalb der Map-funktionen halten find ich ausserdem abenteurlich ... da der iterator durch map-zugriffe (insert, erase, sort ... etc) ungueltig werden kann ....

    wenn du ne map hast ... dann ist der key doch eundeutig ... ( keine Multimap) warum arbeitest ned mit dem key ?

    Ciao ...



  • warum arbeitest ned mit dem key?

    Weil
    1. eine fertige Bibliothek von mir einen eindeutigen 4Byte-Index verlangt.
    2. weil es sich bei dem Key um lange Zeichenketten handelt und diese
    3. möglicherweise auch übers Netz übertragen werden müssen.



  • Trotzdem versteh ich es noch ned ganz ....

    Iterator Problem ...

    In meiner map ist jedes Element durch einen iterator eindeutig definiert

    Nein ... jedes Element in deiner Liste ist durch eindeutige interne Verweise markiert(meistens Pointer), die deine Liste verwaltet. Der Iterator ist ein Hilfsobjekt ... mit welchen Du auf die Elemente deiner Liste zugreifen kannst / musst. Sequentiell oder mittels direktzugriff. Der Iterator ist somit eine Klasse, die interne Verwaltungsinformationen der Liste speichert. Praktischer weisse wurden paar nutzliche Operationen uberschrieben ... wie der = oder == Operator, oder bei speziellen listen der ++ operator ... etc.
    Die iteratoren sind somit in der Lage, Ihre Positionen innerhalb der liste zu veraendern (sich auf das naechste Element zu setzen ... ) oder zu vergleichen, ob sie auf das selbe element zeigen, oder gar zuweisungen zu machen (sich auf ein bestimmtes element der lsite zu setzen).
    Das geafehrliche daran ist, dass die ganze sache nur temporaerer natur ist, sprich wenn du die liste anederst (insert, remove, sort) kann der iterator gar auf ein anderes element ploetzlich zeigen ... oder gar komplett ungueltig werden.

    möglicherweise auch übers Netz übertragen werden müssen.

    Und ich glaub hier liegt ein Verstaendnissproblem vor ... nen iterator ist keine Numerische Positionsangabe. ein Iterator ist eine Instanz einer ziemlich komplexen Klasse. (der ++ Operator ist dementsprechend ueberladen).

    sizeof(std::map<int,int>::iterator) wird dir also definitiv nicht 4 oder so zurueckgeben, sondern ne menge mehr ...

    Willst du die Elemente nummeriert haben , musst etwas mehr machen.
    langt dir die nummer des elements innerhalb der Liste ... und sind sie einigermassen in folge ... dann nimm nen vector.
    Willst flexibler sein ... dann haeng eine eindeutige ID an dein Object ...

    Wenn du nun mittels key (also dienem endlos langen Strings) und auch mittles den Ids Schnell auf deine Elemente zugreifen willst ... musst die container eh combinieren. Sprich ne klasse schreiben ... die dir deine Objecte doppelt verwalltet ... einmal beispielsweise in nem Set nach der Id sortiert ... und dann in nem Set nach den strings sortiert. Die Container halten dann natuerlich nicht jeder das Object ... sondern nur nen Zeiger drauf ...

    Ich hoffe wir sprechen hier von der selben sache, den STL containern. Die MFC beispielsweisse nutzt positionsangaben als eine Art iteratoren (POSITION). Aber achtung auch wenn die Position da numerich ist, ist pos+1 nicht unbedingt das naechste element. Und beim bearbeiten der COntainer aendern sich die Numerischen Positionsangaben auch !!!

    Wenn du nur 4 byte grosse Werte als eindeutige ids uebers netz geben willst, wuerde ich eh Ids fuer deine Objecte anlegen .... die sich nie anedern, solange das Object besteht .... ansonsten kommst en in teufels kueche ....

    Ciao ...


Anmelden zum Antworten