transform

Erhard Henkes

Akzeptiert! Das einfache Beispiel zeigt dennoch, dass STL alles andere als genial ist, eben auch unvollkommen und gerade nicht wirklich high level, sonst würden einfache Dinge eben noch einfacher gehen. Muss mal gesagt werden!

*aleph_0

Mit funktionalen Bibliotheken kann man Funktionsobjekte mit ähnlicher Syntax von richtigen Funktionen "inline" in Funktionen definieren, was leicht zu lesen ist.
http://okmij.org/ftp/c++-digest/Functional-Cpp.html
http://www.boost.org/libs/lambda/doc/ (speziell http://www.boost.org/libs/lambda/doc/ar01s03.html)

volkard

nicht akzeptiert.

for (vector<string>::const_iterator cmd = commands.begin(); cmd != commands.end(); ++cmd)

zeigt einfach nur nen krassen mangel der sprache, nämlich daß es kein foreach gibt.
also hat man zwei möglichkeiten. messer&gabel und innerschleifencodecode in ne struct auslagern oder auswendiglernen und als festes idiom betrachten:

foreach bla in cont

heißt in c++

for (typeof(cont)::const_iterator bla = cont.begin(); bla != cont.end(); ++bla)

und ein wenig warten, ob c++ bald geheilt wird oder ob man abspringen muß.

HumeSikkins

und ein wenig warten, ob c++ bald geheilt wird oder ob man abspringen muß.

Das Fehlen eines foreachs ist zwar wirklich blöd, deshalb aber gleich abzuspringen scheint mir eine Überreaktion zu sein

Irgendwie habe ich gerade ein Déjà Vu

operator void

Ich würde das Problem andersrum sehen: Es gibt ein schickes for_each (und noch viel mehr schöne Algorithmen), aber es gibt keine annehmbare Möglichkeit, Prädikate zu definieren. Wenn man for_each einbauen würde, hätte man zwar den häufigsten Fall lesbarer gemacht, aber find(), generate() etc. wären immer noch hässlich. So etwas wie boost::lambda in C++ einzubauen würde die STL-Algorithmen imho verdammt lesbar und praktisch machen. So in der Art:

for_each(cont.begin(), cont.end())
{
    _1.name = "Heinrich";
}

Dazu müsste C++ "nur" aus dem {}-Block einen Funktor machen (der natürlich alle Variablen im Scope referenzieren darf) und diesen als letztes Argument an for_each übergeben. In Ruby funktioniert das ganze afaik ähnlich (letztes Funktionsargument darf ein Block sein).

Gut möglich, dass ich gerade ein Bisschen arg visioniere *ins Bett sollt*

HumeSikkins

@operator void
Was du willst sind also interne (bzw. passive) Iteratoren. Die wollte ich in meinem vorherigen Beitrag auch schon fordern, hab's dann aber doch lieber gelassen

In der Regel kommt jetzt nämlich gleich einer angerannt und sagt, wir sollten mit einer anderen Sprache programmieren

Helium

interne (bzw. passive) Iteratoren

Irgendwie komme ich damit nicht klar. Intern im Sinn von in die Sprache eingebaut? Passiv im Sinn von was?
Und mit Iterator meinst du das, was in C++ Iteratoren sind oder allgemein "Wiederholer" (wörtliche übersezung) wie es sie z.B. in Sather gibt?

Ich bin stat dessen für das Definiere eigener Kontrollstrukturen, so wie ich operator void verstanden habe.

void foo (Typ parmeter, block mein_block)
{
   call mein_block;
   call mein_block;
}

foo (bar)
{
   ...; 
}

der auf foo folgende Block wird dann zweimal ausgeführt. oder aber sowas:

typedef void (*Function) ();

void foo (Typ parmeter, Function function)
{
   function();
   function();
}

foo (bar, void (*)() {...;} ); // irgendwie unübersichtlich

Bashar

foo (bar, void (*)() {...;} ); // irgendwie unübersichtlich

foo(bar, void lambda() { ... }); // wär besser, aber kostet ein keyword, und darauf reagieren bjarne und co ja bekanntermaßen allergisch

HumeSikkins

@Helium
Es tut mir ja nun leid, aber sowas nennt man nun mal passive Iteratoren (nach Booch) oder interne Iteratoren (GoF). Solche Iteratoren sind letztlich Methoden die einen bestimmten Code-Block (der vom Aufrufer zur Verfügung gestellt wird) ausführen.

operator void

Hm naja, ist for_each dann nicht jetzt schon ein interner/passiver Iterator? Ob Argument #3 nun ein unlesbar mit boost::bind zusammengesetzter Funktor oder ein anonymer Codeblock ist, macht aus der Sicht von for_each doch keinen Unterschied.