Ich mag die STL Datencontainer wie vector und map ja echt gerne. Was mich aber immer unheimlich stört ist, dass man beim durchlaufen der Container solch dicke, aufgeblähte Schleifenköpfe hat:

for (map<boost::shared_ptr<HierEine::TolleKlasse>,boost::shared_ptr<DortEine::TolleKlasse>>::const_iterator it = data->d.begin(); it!= data->d.end(); it++) {
    tuwas(*it);
}

Da blähen sich schon die einfachsten for-Schleifen zu unübersichtlichen Codewürsten auf. Die Übersicht leidet enorm. Und außerdem hagelts mir bei solchen Konstrukten auch ständig Kompilierfehler, weil ich mal wieder irgendwo ein Klämmerchen vergessen habe. Die Holzkammermethode ist da schon wesentlich kompakter:

for (int i = 0; i < data->d.size(); i++) {
    tuwas(data->d[i]);
}

Gibt es denn keine Möglichkeiten, diesen Iteratorenwahnsinn ein bisschen zu entschlacken und die Container trotzdem ordentlich zu durchlaufen?

Was nichts daran änder, daß der Code woanders steht.

Eben !
Großer Vorteil von for_each() !

Gruß,

Simon2.

Schon mal was von Modularität gehört?

Mit for_each lassen sich "die Operation" und "führe auf jedem von einer Reihe von Objekten aus" hervorragend trennen

#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);

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.

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.

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.

(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

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.

http://www.joelonsoftware.com/items/2006/08/01.html

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.

http://www.joelonsoftware.com/items/2006/08/01.html

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.

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.

map( function(x){x.print();}, a );

statt

// irgendwo an einer völlig anderen Stelle
struct PrintAdapter {
   template<class T>
   void operator()(const T& x) const {
     x.print();
   }
};
// und dann wiederum an einer anderen Stelle
map( PrintAdapter(), a );

Die Frage: "Wo bitte ist der Vorteil, dass der Code woanders steht?" bleibt imo völlig berechtigt und hat nichts mit map/foreach/... vs. for-Schleifen zu tun. Anders: for-Schleifen sind nicht deshalb mist weil der Code, der pro Iteration ausgeführt wird im Body der Schleife steht, sondern weil das Iterieren nicht abstrahiert ist.

Die Frage: "Wo bitte ist der Vorteil, dass der Code woanders steht?" bleibt imo völlig berechtigt und hat nichts mit map/foreach/... vs. for-Schleifen zu tun.

Du vergisst, dass *ich* derjenige war, der BOOST_FOREACH in diesem Thread vorschlug. Ich bin auf Deiner Seite, Du musst mich nicht überzeugen. Trotzdem sind auch die in der Schleife vollführten Operationen oft dieselben, parametrisierbaren Algorithmen (z.B. beim Filtern ein less_than-Vergleich oder beim Aufeinanderfalten (Reduzieren) eine einfache Addition), und in solchen Fällen lohnt es sich eben, wiederverwendbare Funktoren zu schreiben.

Trotzdem sind auch die in der Schleife vollführten Operationen oft dieselben, parametrisierbaren Algorithmen (z.B. beim Filtern ein less_than-Vergleich oder beim Aufeinanderfalten (Reduzieren) eine einfache Addition), und in solchen Fällen lohnt es sich eben, wiederverwendbare Funktoren zu schreiben.

Es lohnt sich eine Abstraktion (Funktion) für "Filtern" und "Aufeinanderfalten" zu schreiben. Da stimme ich zu und deshalb bin ich ja auch ein großer Freund von einfachen Standardalgos wie std::for_each oder std::accumulate. Es lohnt sich aber imo keinesfalls eine Funktion für "less_than"-Vergleich oder "einfache Addition" zu schreiben und deshalb mag ich ja auch die einfachen Standardalgos wie std::for_each und std::accumulate nicht (der Widerspruch ist beabsichtigt). Denn ohne boost::lambda o.Ä. schreibt man ständig irgendwelche völlig trivialen Funktoren oder aber unglaublich generische, die dann über 5 Binder zusammengeschustert werden und damit am Ende nur eins produzieren: Unverständnis beim Leser.

C++ ist halt eine wunderbare Multiparadigmen-Sprache -)