template-Frage:

SeppJ

huuuuuuuuuu schrieb:

typename -> class?

Ähhhh, vielleicht solltest du nochmal mit den Grundlagen von Templates anfangen, bevor du kompliziertere Sachen baust. Da das Thema zu groß für einen Forenbeitrag ist: Buch schnappen.

cooky451

@huuu..
Einer der beiden Templateparameter ist ein Typ, der andere ist selbst ein Template. Jetzt rate mal, was wozu gehört.
PS: Iterator++

SeppJ

cooky451 schrieb:

PS: Iterator++

Falls das immer der gleiche huuuu mit egal wie vielen uuuus ist, noch ein weiterer Tipp: Versuch nicht in C++ Lisp zu programmieren. Das scheitert schon immer grandios, wenn Java-Programmierer in C++ versuchen Java zu programmieren, dabei besteht zwischen Java und C++ zumindest eine gewisse Ähnlichkeit. Das ist in keiner Sprache eine gute Idee, sich von den bewährten Prinzipien weg zu bewegen.
Daher: Die STL ist aus gutem Grund mit Iteratoren implementiert, eben weil der Ansatz den Listentyp als ganzes zu übergeben Mist ist. Du kannst vielleicht noch darüber streiten, ob Iteratoren oder Ranges besser sind. Oder ein ganz neues Prinzip. Aber dazu müssen diese Prinzipien erst einmal mindestens genauso flexibel wie Iteratoren sein, dann kann man darüber reden.

cooky451

Wobei ich ja so eine Überladung schon nett finden würde:

template<class Container, class Function>
Function for_each(Container container, Function function)
{
  return for_each(begin(container), end(container), function);
}

Aber bevor man anfängt mit Templates als Templateparameter rumzuwurschteln..

SeppJ

cooky451 schrieb:

Wobei ich ja so eine Überladung schon nett finden würde:
[...]

Also die C++11 range-based loops?

314159265358979

Bei Template-Template-Parametern muss es übrigens

template
<
    template <typename> class foo
    typename bar
>

heißen, wobei statt des typenames auch class verwendet werden kann. Das class ist allerdings Pflicht.

cooky451

SeppJ schrieb:

Also die C++11 range-based loops?

Ok, foreach war vielleicht ein schlechtes Beispiel, weil man das eigentlich eh vergessen kann. (Sobald Microsoft sich mal gnädig zeigt und die range-based Loops dann auch implementiert..)
Aber den anderen Algorithmen würde eine Überladung der man einfach den Container übergeben kann auch nicht schaden.

Statt

std::remove_if(std::begin(container), std::end(container), [] (const Element &element) { return element.foo(); });

Kommt dann:

std::remove_if(container, [] (const Element &element) { return element.foo(); });

Warum nicht gleich konsistent zu for bleiben?

std::remove_if (const Element& element : container) {
  return element.foo();
}

krümelkacker

cooky451 schrieb:

...

std::begin(container)
  std::end(container)

Mal so am Rande: Ich weiß nicht, ob das so eine gute Idee ist, begin/end zu qualifizieren. Bei swap tue ich das jedenfalls nicht, nicht in generischem Code. Mit der Qualifizierung schaltest Du nämlich ADL aus.

cooky451

krümelkacker schrieb:

Mal so am Rande: Ich weiß nicht, ob das so eine gute Idee ist, begin/end zu qualifizieren. Bei swap tue ich das jedenfalls nicht, nicht in generischem Code. Mit der Qualifizierung schaltest Du nämlich ADL aus.

Ich weiß, so ganz einig bin ich mir auch nicht. Aber Arrays kommen leider nicht aus std::. Alles etwas suboptimal. Operatoren hätten ja nicht geschadet, aber ich glaube das hatten wir sogar schon mal. Ja, genau: http://www.c-plusplus.net/forum/294688