std::map<> und Iteratoren.



  • sinnfrei schrieb:

    Tja - keine Ahnung warum du denkst, du bräuchtest eine zweite map

    Wenn du eine bessere Idee hast, nur her damit. 😉



  • Ne, zwei Maps sind nervig. 🙂

    Also, dann scheine ich dein Problem immer noch nicht verstanden zu haben.

    Ich habe folgendes verstanden: Du hast eine Map<string, X> und begin/end-Iteratoren auf irgendwelche strings. Jetzt möchtest du wissen, ob der string [begin, end) in deiner Map vorhanden ist oder nicht? Stimmt das?



  • Irgendwer schrieb:

    Ich habe folgendes verstanden: Du hast eine Map<string, X> und begin/end-Iteratoren auf irgendwelche strings. Jetzt möchtest du wissen, ob der string [begin, end) in deiner Map vorhanden ist oder nicht? Stimmt das?

    Ja. Aber ohne jedes Mal einen neuen std::string erstellen zu müssen.



  • Ich hoffe ich hab folgendes richtig verstanden:

    • du möchtest eine std::map<string, x> verwenden, wobei x für irgendeinen Datentyp steht.
    • du hast allerdings nur zwei std::string::const_iterator(en)

    Jetzt will mir nicht ganz klar sein, was genau gegen

    typedef std::map<std::string, irgendwas> myMap;
    typedef std::string::const_iterator cStrIt;
    // ...
    void mapInsert(cStrIt& beg, cStrIt& end, irgendwas value) {
        myMap[std::string(beg,end)] = value;
    }
    

    spricht.
    Wozu solltest du hier eine zweite map benötigen, wenn es ohnehin nicht perfomancerelevant ist, dass du jedesmal temporäre string-obj erstellst?

    Deine Klasse Range ist ja nichts anderes als ein wrapper um einen string - nicht mehr. Also kannst du ihn dir auch gleich sparen, weil du einfach nichts gewinnst wenn du eine std::map<Range,x> anlegst.
    Du musst das Range-obj erstellen, und im Konstruktor wird dann wiederrum der string erzeugt. Also kannste auch gleich string nehmen.



  • moep - natürlich muss eine map vom Typ myMap erstellt werden, nicht direkt darauf gearbeitet werden .... Oo
    Hatte erst was anderes da stehen und einfach vergessen entsprechend richtig zu editieren. Sollte aber klar sein was ich meinte.



  • Irgendwer2 schrieb:

    Wozu solltest du hier eine zweite map benötigen, wenn es ohnehin nicht perfomancerelevant ist, dass du jedesmal temporäre string-obj erstellst?

    Es ist nicht performancerelevant, wie lange es dauert einen neuen String in die Map einzufügen. Es ist sehr relevant, wie lange es dauert um ein Element zu finden.

    Irgendwer2 schrieb:

    Du musst das Range-obj erstellen, und im Konstruktor wird dann wiederrum der string erzeugt. Also kannste auch gleich string nehmen.

    Nein. Die Konstruktoren für (std::string) und (const char*) erzeugen einen String. Der (iterator, iterator) erzeugt keinen. Der Kopier-Konstruktor erzeugt nur einen String, wenn die kopierte Range auch einen eigenen String hat.



  • Was ich aber gleich sagen kann ist, dass es mir nicht darum ging, dass ich den String das eine Mal nicht kopieren muss. Bzw. irgendwie schon, aber an der Stelle ist Performance egal.

    Es ist sehr relevant, wie lange es dauert um ein Element zu finden.

    Wie passt das zusammen?

    Nebenfrage: Wie kommst du überhaupt an diese Iteratoren? Wieso hast du keine Möglichkeit direkt mit den Strings zu arbeiten?

    Vielleicht macht es mehr Sinn, das Design so zu vereinfachen, dass du mit Strings hantieren kannst, anstatt dir so eine komische Range Klasse zu bauen.

    Aber wenn das alles nicht geht, scheinst du ja mit der Range eine Lösung gefunden zu haben.



  • Irgendwer schrieb:

    Wie passt das zusammen?

    Die Bemerkung bezog sich nur auf das Einfügen in die Map. Sorry, falls das missverständlich war.

    Irgendwer schrieb:

    Nebenfrage: Wie kommst du überhaupt an diese Iteratoren? Wieso hast du keine Möglichkeit direkt mit den Strings zu arbeiten?

    Jain. Also ja, aber dann müsste ich dauernd Substrings erstellen - was auch nicht Sinn der Sache ist. So muss ich nur Iteratoren hin und her bewegen.

    Irgendwer schrieb:

    Aber wenn das alles nicht geht, scheinst du ja mit der Range eine Lösung gefunden zu haben.

    Hmja, ich mache gerade ein paar Tests und der Performancegewinn bewegt sich zwischen Faktor 25 und 1. Da soll man mal schlau draus werden. 😃



  • 😃



  • cooky451 schrieb:

    Irgendwer2 schrieb:

    Wozu solltest du hier eine zweite map benötigen, wenn es ohnehin nicht perfomancerelevant ist, dass du jedesmal temporäre string-obj erstellst?

    Es ist nicht performancerelevant, wie lange es dauert einen neuen String in die Map einzufügen. Es ist sehr relevant, wie lange es dauert um ein Element zu finden.

    cooky451 schrieb:

    Irgendwer schrieb:

    Ich habe folgendes verstanden: Du hast eine Map<string, X> und begin/end-Iteratoren auf irgendwelche strings. Jetzt möchtest du wissen, ob der string [begin, end) in deiner Map vorhanden ist oder nicht? Stimmt das?

    Ja. Aber ohne jedes Mal einen neuen std::string erstellen zu müssen.

    Zeig mal den Code mit dem du gemessen hast, dass das Erstellen viel länger braucht als das Suchen und Vergleichen.


Anmelden zum Antworten