3. for_each mit memberfunktionen

for_each mit memberfunktionen

  • ?

    Hallo zusamms,
    ich habe (hatte) folgendes Problem:
    Ich würde gerne alle Elemente eines STL-Vektors hintereinander als Argument von eine Methode einer Klasse übergeben, also ein Äquivalent für:

    myclass *myobj;
vector<int> a;

// void myclass::doit(int wert)
myobj->doit(a[0]);
myobj->doit(a[1]);
myobj->doit(a[2]);
// usw...

    Hier bietet sich natürlich ein for_each an, jetzt muss ich nur noch die Methode doit der Klasse (*myobj) in ein "unäres Funktionsobjekt" (heisst das so?) umwandeln, die Lösung, die ich gefunden habe ist:

    myclass *myobj;
vector<int> a;

for_each(a.begin(),a.end(), bind1st(mem_fun(&myclass::doit)), myobj));

    Gibt es eine andere Möglichkeit, als das umständliche

    bind1st(mem_fun(&myclass::doit)), myobj))

    Konstrukt?
    LG, J.

    0
  • G

    Wieso nicht einfach

    for (vector<int>::iterator it = a.begin(); it != a.end(); ++it)
    myobj->doit(*it);

    ?

    0
  • R

    mit boost::bind kannst du das schneller machen

    for_each(v.begin(),v.end(),boost::bind(&myclass::doit,myobj));
    0
  • ?

    Du meinst hoffentlich

    std::for_each(v.begin(), v.end(), boost::bind(&myclass::doit, myobj, _1));

    oder? 😉

    0
  • C

    Gerade in Hinblick auf groovemasters Posting: Ist die Verwendung eines STL-Algorithmus wirklich signifikant schneller als das "Ausschreiben" einer normalen for-Schleife? Welchen Nutzen hat erstere noch, außer, daß sie eine kürzere Schreibweise hat?

    0
  • O

    dass du dich nicht um das kümmern musst, was for_each für dich erledigt?
    for_each ist fehlerfrei, schon allein deshalb sollte mans benutzen, bevor man einen schusselfehler einbaut 🙂

    0
  • B

    dass du dich nicht um das kümmern musst, was for_each für dich erledigt?

    Das ist ja auch so höllisch kompliziert.

    0
  • W

    Cocaine: Für oft wiederkehrende Sachen ist es ganz hübsch, aber gerade bei speziellen Sachen die uU nur einmal im Programm vorkommen schreibt man sich ne Schleife statt einen extra-Functor zu bauen.

    0
  • C

    otze schrieb:

    dass du dich nicht um das kümmern musst, was for_each für dich erledigt?
    for_each ist fehlerfrei, schon allein deshalb sollte mans benutzen, bevor man einen schusselfehler einbaut 🙂

    Ich find die zweizeilige for-Schleife zunächst mal leichter nachzuvollziehen, als den UnaryFunction-Kram. Klar gewöhnt man sich dran, aber das ist doch nur sinnvoll, wenn man auch was von hat, oder nicht?

    edit
    @Mastah: Ok, hübsch ist es - zumal man sofort an for_each, find, transform etc. erkennt, was Sache ist und nicht erst die for-Schleife durchgucken muß. Das kann ein Kommentar allerdings auch...

    0
  • H

    Cocaine: Für oft wiederkehrende Sachen ist es ganz hübsch, aber gerade bei speziellen Sachen die uU nur einmal im Programm vorkommen schreibt man sich ne Schleife statt einen extra-Functor zu bauen.

    Imo aber nicht deshalb, weil es der bessere Weg ist sondern weil es C++ hier einem unnötig schwer macht.

    Ich bevorzuge in solchen Situationen BOOST_FOREACH:

    BOOST_FOREACH(int i, vec)
{
    myObj.doIt(i);   
}

    Letztlich fände ich ein eingebautes for_each oder von mir aus auch ein Block-Konstrukt zusammen mit Lambda-Ausdrücken schöner.

    0
Anmelden zum Antworten