ich möchte einen Vektor mit Zahlen initialisieren bisher habe ich das so gemacht:

std::vector<unsigned int>zahlen(10);
for(int i=0;i<zahlen.size();i++)
   zahlen[i] = i;

Gibt es irgendeinen Grund warum ich mir einen Funktor schreiben sollte und damit den Vektor initialisere so z.B. :

class count_up
{
public:
	count_up(T start):start_wert(start){};
	void operator()(T &wert)
	{
		wert = start_wert++;
	};
private:
	T start_wert;
};

std::vector<unsigned int>zahlen(10);
std::for_each(zahlen.begin(),zahlen.end(),count_up<unsigned int>(0));

Wann sollte man Funktoren verwenden? Sollte man für jede kleine Aufgabe einen Funktor verwenden?

mfg

Wann sollte man Funktoren verwenden? Sollte man für jede kleine Aufgabe einen Funktor verwenden?

So, wie du fragst, weisst du die Antwort sicher schon selber: Natürlich nicht.

Funktoren lohnen sich vor allem, wenn du sie mehrfach anwenden kannst oder du die Füllfunktion von der Initialisierung trennen willst. Für gewisse Operationen sind sie aber notwendig (oder alternativ Funktionszeiger), z.B. als Sortierkriterium. Wenn du dir bei deinem Beispiel unwohl vorkommst und dir nicht die Mühe machen willst, für einen einzigen Fall gleich viel mehr Code zu schreiben, dann lass es. Der Code wird nicht zwingend besser, wenn er mehr auf STL-Style setzt. Da ist auch viel Geschmackssache dabei.

McCoolCool schrieb:

Mit meinem Laienwissen würde ich annehmen das beide Varianten gleich schnell seien müssten.

Falls du einen modernen Compiler verwendest, ist das aufgrund der Optimierungen stark anzunehmen. Selbst Funktionszeiger sollten nicht mehr allzu grosse Probleme bereiten, wenn sie Zur Kompilierzeit offen vorliegen.

1. der Functor nicht kopiert wird und
2. die Reihenfolge bei for_each immer von vorne nach hinten in einem Rutsch durchgeht.
   Eine Möglichkeit wäre z.B. dass bei jedem Schleifendurchlauf der Anfangs übergebene Functor kopiert wird und du am Ende mit einem vector voller Nullen dastehst, was ja nicht deine Absicht war.

2. die Reihenfolge bei for_each immer von vorne nach hinten in einem Rutsch durchgeht.

Der Standard garantiert, dass die Iteratoren in for_each() von first beginnend bis last - 1 durchgegangen werden. Das ist (soweit ich weiß) der einzige Algorithmus neben copy() , für den diese Garantie gegeben wird. Natürlich löst das das Problem mit der Kopie nicht.

25.1.1 For each schrieb:

Effects: Applies f to the result of dereferencing every iterator in the range [first, last), starting from first and proceeding to last - 1.

das mit dem funktor hab ich aber noch nicht gewusst... hab den fehler vrmtl auch schon x-mal gemacht ><

bb

bb

Der C++-Standard ist hier nicht 100% genau:

25.2.6 schrieb:

template<class ForwardIterator, class Generator>
void generate(ForwardIterator first, ForwardIterator last, Generator gen);

template<class OutputIterator, class Size, class Generator>
void generate_n(OutputIterator first, Size n, Generator gen);

1 Effects: Invokes the function object gen and assigns the return value of gen though all the iterators in the range [first, last) or [first, first + n).

Dass die Iteratoren nicht in der Reihenfolge laufen, bedarf schon fast einer böswilligen Interpretation.

Gibt es irgendeinen Grund warum ich mir einen Funktor schreiben sollte und damit den Vektor initialisere ...

zunächst mal keinen (außer s.u.)

Nexus schrieb:

Da ist auch viel Geschmackssache dabei.

Das ist wohl in letzter Instanz das ausschlaggebende Kriterium.

volkard schrieb:

Was wäre denn bei einem gigantisch großen vector schneller?

Geschwindigkeit ist nicht alles, ein Kriterium 'pro Funktor' ist die schlichte Tatsache, dass man dabei weniger Fehler machen kann - wenn es der Compiler erst mal gefressen hat! Folgendes z.B.:

for(int i=0;i<=zahlen.size();i++)
   zahlen[i] = i;

wird zur Laufzeit nicht gleich schiefgehen, sondern vielleicht erst später und beim Kunden - und dann wird's teuer. Beim Einsatz von [begin(),end()) tut man sich schon schwerer, so einen Fehler zu machen.

Aber wenn wir schon bei einem Container mit 10 Elementen über Geschwindigkeit reden, dann ist z.B. diese Lösung mit dem boost.counting_iterator

#include <boost/iterator/counting_iterator.hpp>
std::vector<unsigned int> zahlen( boost::counting_iterator< unsigned int >(0), boost::counting_iterator< unsigned int >( 10 ) );

zumindest theoretisch fast um den Faktor 2 schneller, da die Initialisierung von vector<> mit dem Füllen desselben zusammenfällt. Ob sie's dann wirklich ist, hängt wohl im wesentlichen von den Fähigkeiten des verwendeten Compilers ab.
Was oft vergessen wird ist, dass

std::vector<unsigned int>zahlen(10);

bereits eine interne Schleife mit vector<>.size() Durchläufen initiiert, um alle Elemente mit 0 zu belegen.

Gruß
Werner

abgesehen davon wird hier ein stateful functor benutzt, was zu bösen Überraschungen führen kann. Der Standard garantiert nämlich nicht, dass

1. der Functor nicht kopiert wird und

Wieso wäre das denn überhaupt ein Problem?
Ich hab noch mal drüber nachgeguckt und wenn eine Kopie angelegt wird, dann sollte das doch auch keine Probleme machen!?

bb

Ich hab noch mal drüber nachgeguckt und wenn eine Kopie angelegt wird, dann sollte das doch auch keine Probleme machen!?

Nicht in der heutigen Implementierung der stdlib.
Bei dem Iteratorpaar ist alles übers Kopieren gesagt und das klappt auch.
Bei dem Funktor, der sich wie ein Wert anfühlt, erwarte ich, daß normale Wert-Optimierungen greifen dürfen, wie daß mehrere Threads zum Array-Initialisieren benutzt werden, da macht das Kopieren Ärger.

wurde schon gesagt, habe nicht genau genug gelesen

Geschwindigkeit ist nicht alles, ein Kriterium 'pro Funktor' ist die schlichte Tatsache, dass man dabei weniger Fehler machen kann - wenn es der Compiler erst mal gefressen hat! Folgendes z.B.:

for(int i=0;i<=zahlen.size();i++)
   zahlen[i] = i;

wird zur Laufzeit nicht gleich schiefgehen, sondern vielleicht erst später und beim Kunden - und dann wird's teuer. Beim Einsatz von [begin(),end()) tut man sich schon schwerer, so einen Fehler zu machen.

Was hat das jetzt mit Funktor zu tun? begin(),end() kann man in der Schleife auch ohne Funktor verwenden.