STL Datencontainer, Iteratoren und die dicken Köpfe...
-
Bastel dir doch ein
typedef. Wobeifor (...) it->tuwas();eigentlich eher noch nachfor_eachschreit.
-
for_each ist blöd, weil man da noch nen Funktor braucht und der Code deshalb an ganz anderer Stelle steht. (Außer man nimmt boost::lambda, dann wirds aber auch nicht grade übersichtlicher als die Schleife.)
-
Nein, man braucht nicht unbedingt einen Funktor, ein Funktor ist nur ein elegantes Werkzeug, man kann auch Funktionspointer übergeben
-
Was nichts daran änder, daß der Code woanders steht.
-
Tyrdal schrieb:
Was nichts daran änder, daß der Code woanders steht.
Eben !
Großer Vorteil von for_each() !
Gruß,
Simon2.
-
Was zum Henker soll daran ein Vorteil sein?
-
Das du die Funktion auch von anderen Stellen aus benutzen kannst? Das du die Implementierung unabhängig davon austauschen kannst?
Schon mal was von Modularität gehört?
-
"Ich führe die Operation auf einem Objekt aus"
"Ich führe die Operation auf jedem von einer Reihe von Objekten aus"Mit for_each lassen sich "die Operation" und "führe auf jedem von einer Reihe von Objekten aus" hervorragend trennen
-
Wenn Du eh schon Boost verwendest, dann rate ich Dir zu BOOST_FOREACH:
#include <boost/foreach.hpp> #define foreach BOOST_FOREACH // … typedef map<boost::shared_ptr<A>, boost::shared_ptr<B> >::const_iterator citer_t; foreach(citer_t i, data) tuwas(*i);
-
Tyrdal schrieb:
for_each ist blöd, weil man da noch nen Funktor braucht und der Code deshalb an ganz anderer Stelle steht. (Außer man nimmt boost::lambda, dann wirds aber auch nicht grade übersichtlicher als die Schleife.)
Ja, fast richtig. Allerdings gibt's für die Implementierung eines simplen objekt->tuwas(arg) viele, tolle, generische Bausteine.
Dass Boost.Lambda nicht übersichtlicher ist, möchte ich jedoch bezweifeln. Vor allem ist es deutlicher.
-
Danke für die vielen hilfreichen Tipps. BOOST_FOREACH scheint mir für meinen Fall der geeignetste Weg zu sein.
-
Das du die Funktion auch von anderen Stellen aus benutzen kannst? Das du die Implementierung unabhängig davon austauschen kannst?
Kommt bei mir aber extrem selten vor, daß ich Code, der in solchen Schleifen steht, irgendwo wiederverwenden kann.
Schon mal was von Modularität gehört?
Schon, ist aber in dem Fall unnötig, s.o.. Allein kann ich mit meiner Meinung ja nicht dastehen, sonst gäbe es ja das BOOST_FOREACH Makro ja nicht. Das paßt besser zu meinem Stil.
-
Tyrdal schrieb:
Das du die Funktion auch von anderen Stellen aus benutzen kannst? Das du die Implementierung unabhängig davon austauschen kannst?
Kommt bei mir aber extrem selten vor, daß ich Code, der in solchen Schleifen steht, irgendwo wiederverwenden kann.
Hmm. Finde ich komisch, denn eigentlich lassen sich die meisten Aufgaben, die in Schleifen ausgeführt werden, recht gut auf einige Basisoperationen reduzieren, die man dann mit Map- und Filter-Operationen verknüpfen kann (wobei ein Map eine Funktion T -> T ist, während ein Filter eine Funktion T -> bool ist, die Elemente aussortiert). Andere Programmiersprachen (Haskell …) basieren auf dieser Annahme und sind da recht erfolgreich mit.
-
Dann ist das der Grund warum ich mich bisher nicht mit funktionaler Programmierung anfreunden konnte.
Aber mal im Ernst, gib mal ein wiederwendbares Beispiel an. Vielleicht lern ich ja dann noch was.
-
Konrad Rudolph schrieb:
(wobei ein Map eine Funktion T -> T ist, während ein Filter eine Funktion T -> bool ist, die Elemente aussortiert).
Wobei das natürlich nur die Signaturen der Argumentfunktionen sind.
map :: (\T -> T), [T] -> [T] filter :: (\T -> bool), [T] -> [T] foldl :: (\T, T -> T), T, [T] -> T
-
Tyrdal schrieb:
Dann ist das der Grund warum ich mich bisher nicht mit funktionaler Programmierung anfreunden konnte.
Aber mal im Ernst, gib mal ein wiederwendbares Beispiel an. Vielleicht lern ich ja dann noch was.
-
finix schrieb:
Tyrdal schrieb:
Dann ist das der Grund warum ich mich bisher nicht mit funktionaler Programmierung anfreunden konnte.
Aber mal im Ernst, gib mal ein wiederwendbares Beispiel an. Vielleicht lern ich ja dann noch was.Grmpf, vielen Dank! Ich wollte vorhin schon einen Link auf MapReduce von Google posten, aber ich wusste den genauen Namen nicht mehr (ich habe mich nur an die Haskell-Terminologie erinnert, also „reduce“ = „fold“) und habe nichts gefunden.
-
Java required you to create a whole object with a single method called a functor if you wanted to treat a function like a first class object. Combine that with the fact that many OO languages want you to create a whole file for each class, and it gets really klunky fast. If your programming language requires you to use functors, you're not getting all the benefits of a modern programming environment. See if you can get some of your money back.
So ganz kommt die Seite also auch nicht an meinem Argument vorbei. Wobei der Hinweis auf die einfachere Parallelisierung ein echtes Argument ist. Aber das kann man ja im Bedarfsfall so machen und für den Rest BOOST_FOREACH nehmen.
Ansonsten danke ich für die Begegnung mit den Muppets. Ich liebe sie.
-
Tyrdal schrieb:
Java required you to create a whole object with a single method called a functor if you wanted to treat a function like a first class object. Combine that with the fact that many OO languages want you to create a whole file for each class, and it gets really klunky fast. If your programming language requires you to use functors, you're not getting all the benefits of a modern programming environment. See if you can get some of your money back.
So ganz kommt die Seite also auch nicht an meinem Argument vorbei.
Na ja, dafür gibt es in C++ ja Boost.Lambda und ähnliches. Nur weil es Java nicht kann, heißt es noch lange nicht, dass da andere Sprachen nicht weiter sind.
-
Schon richtig, aber ich hab ja in einem vorherigen Post geschrieben, daß ich die Sache mit boost::Lambda nicht übersichtlicher find. Und außer für Parallelisierung seh ich da jetzt auf der Seite keinen Vorteil, der die schlechtere Lesbarkeit (in C++)rechtfertigen würde. Naja ist wohl Geschmackssache.