int f(int, int);
int g(int, int);

const auto Funktionszeigerarray ={f,g};

§8.5.4/2 schrieb:

The template std::initializer_list is not predefined;
if the header <initializer_list> is not included prior to a use of std::initializer_list — even an implicit use in which the type is not named (7.1.6.4) — the program is ill-formed.

Nachdem beide behoben werden geht das wunderbar.
Ideone.

const std::array<decltype(&f),2> Array = {f,g};

/home/tk/Dokumente/Komponist/CantusFirmus.cpp:93:6: warning: suggest braces around initialization of subobject [-Wmissing-braces]

Was kann man da machen?

Wie kann ich folgendes realisieren (clang++ 3.2 gibt einen Error)

int f(int, int);
int g(int, int);

const auto Funktionszeigerarray ={f,g};

Das geht so nicht. {f,g} ist eine initializer_list . Also ist auto vom Typ initializer_list . auto + initializer_list ist wohl ne Pitfall.

§8.5.4/2 schrieb:

The template std::initializer_list is not predefined;
if the header <initializer_list> is not included prior to a use of std::initializer_list — even an implicit use in which the type is not named (7.1.6.4) — the program is ill-formed.

Danke, nicht gewusst.

Das geht so nicht.

Siehe oben. Edit: Du meintest was anderes, sry.

auto + initializer_list ist wohl ne Pitfall.

Nein, ist sie nicht. Die Semantik ist absolut gewollt und in Ordnung.

Natürlich sollte man initializer_list nur nicht - wie auch schon im verschiedenen Threads mehrmals erklärt - als allgemeinen Container abstempeln, weil es keiner ist. Es 'contained' nichts*.
std::array .

#include <iostream>
#include <functional>
using namespace std;

int f(int i, int u) {return i+u;}
int g(int i, int u) {return i+u;}

int main()
{
    array< function<int(int,int)>, 2 > ar = {{f,g}};
    cout << ar[0](1,2) << '\n';
    cout << ar[1](3,4) << '\n';
}

Sone schrieb:

Das geht so nicht.

Siehe oben. Edit: Du meintest was anderes, sry.

"Geht so nicht" war darauf bezogen, dass er so kein Array bekommt. Und er will ja ein Array.

Sone schrieb:

auto + initializer_list ist wohl ne Pitfall.

Nein, ist sie nicht. Die Semantik ist absolut gewollt und in Ordnung.

Natürlich ist das vom Standard so gewollt und in Ordnung. Das heißt aber nicht, dass mein Hirn das für in Ordnung hält.

Sone schrieb:

Natürlich sollte man initializer_list nur nicht - wie auch schon im verschiedenen Threads mehrmals erklärt - als allgemeinen Container abstempeln, weil es keiner ist. Es 'contained' nichts*.
std::array .

hab hinbekommen mit

const std::array<decltype(&f),2> Array = {f,g};

Wenn du schon Funktionszeiger willst, warum nicht explizit die Notation mit Adressoperator, also {&f, &g} benutzen? Wäre dann auch konsistent mit dem decltype .

<>

warum nicht explizit die Notation mit Adressoperator, also {&f, &g} benutzen?

Weil das unnötig ist und es schwerer zu lesen macht. Und die Konsistenz wird genau dadurch relativiert.

auto + initializer_list ist wohl ne Pitfall.

Nein, ist sie nicht. Die Semantik ist absolut gewollt und in Ordnung.

Ist es doch.
Wenn man sowas wie der OP im Kopfbeitrag hier schreibt, dann will man nen Container als Ergebnis. Bekommt aber ne initializer_list .
Aber vielleicht solltest du das Wort Pitfall mal nachschlagen...

Sone schrieb:

auto + initializer_list ist wohl ne Pitfall.

Nein, ist sie nicht. Die Semantik ist absolut gewollt und in Ordnung.

Ist es doch.
Wenn man sowas wie der OP im Kopfbeitrag hier schreibt, dann will man nen Container als Ergebnis. Bekommt aber ne initializer_list .
Aber vielleicht solltest du das Wort Pitfall mal nachschlagen...

Danke, ich weiß, was pitfall heißt. Ich kann englisch, genau wie du.

Und ich sage: Wer einen Container will, muss schon explizit hinschreiben welchen. Ich sehe ja, dass C++11-Anfänger da in eine Art Falle tappen könnten, trotzdem geht die Deduzierung bei auto nun einmal ganz logisch vonstatten.

#include <iostream>
#include <string>
#include <tuple>

struct blau_t 
{
    std::string str_;

    explicit blau_t(std::string str) : str_(str) {}
};

void f(int i, int j) { std::cout << "f(" << i << "," << j  <<")\n"; }
void g(int i, double j) { std::cout << "g(" << i << "," << j  <<")\n"; }
void h (blau_t blau) { std::cout << "h -> " << blau.str_ << "\n";}

int main() 
{
    auto fun_array = std::make_tuple(f,g,h);

    std::get<0> (fun_array) (1,2);
    std::get<1> (fun_array) (1,2.5);
    std::get<2> (fun_array) (blau_t("Hallo"));

    return 0;
}

http://ideone.com/StWGin

Warum nicht std::tuple:

Ich denke, es geht hierbei darum, Funktionen mit gleichen Signaturen in einen Container zu speichern. Tuples verwendet man ja meistens bei verschiedenen Typen.
Ich sehe ich auch nicht so den Sinn darin, jedesmal std::get aufzurufen, wenn man genausogut gleich g und h verwenden könnte, aber darin, die Funktion dynamisch auszuwählen schon.

Warum nicht std::tuple:

Darum. Es macht hier keinen Sinn. tuple findet praktisch nur mit variadic templates eine Daseinsberechtigung. Es ist viel zu statisch. Schon nur um auf das n-te Element zuzugreifen (wobei n ein erst zur Laufzeit feststehender Wert ist) braucht man einen Workaround.

Warum nicht std::tuple:

Darum. Es macht hier keinen Sinn. tuple findet praktisch nur mit variadic templates eine Daseinsberechtigung. Es ist viel zu statisch. Schon nur um auf das n-te Element zuzugreifen (wobei n ein erst zur Laufzeit feststehender Wert ist) braucht man einen Workaround.

Tuple ist genial. Damit können sogar Funktionsobjekte ohne Overhead gespeichert werden. Und ein foreach ist auch recht einfach zu schreiben.

Das Stichwort "variadic templates" hat in diesem Zusammenhang aber gar keinen Sinn. Und praktisch keine Daseinsberechtigung. Es ist etwas völlig anderes. Tuple ist ein Weg, variadic templates zu vermeiden.

Damit können sogar Funktionsobjekte ohne Overhead gespeichert werden.

Zeig was du meinst.

Und ein foreach ist auch recht einfach zu schreiben.

Wovon redest du?

Zeig mal ein wenig Code!

Danke, ich weiß, was pitfall heißt. Ich kann englisch, genau wie du.

Und ich sage: Wer einen Container will, muss schon explizit hinschreiben welchen.

"Ist ein Stolperstein" bedeutet weder "ist schlecht" noch "sollte geändert werden".
Klar ist es logisch. Und vermutlich wäre es auch keine gute Idee es zu ändern.

Nur "ist logisch" heisst halt nicht "jeder Anfänger checkt es". Und damit ist die Aussage "ist ein Stolperstein" mMn. richtig.

Ich sehe ja, dass C++11-Anfänger da in eine Art Falle tappen könnten, trotzdem geht die Deduzierung bei auto nun einmal ganz logisch vonstatten.

Na siehste, du hast es ja eh verstanden.
Ich denke mal du hast einfach zuviel in - zumindest meine - Aussage hineininterpretiert. Ich hab' ja nicht vorgeschlagen dass es geändert werden sollte.
Ich hab lediglich geschrieben dass, wenn man sowas schreibt (was man halt nicht tun sollte), man vermutlich was anderes will als man dann bekommt.

ps: Wenn man jeden Stolperstein für Anfänger den eine Sprache bietet entfernt, dann kommt vermutlich 'was raus was man als Anfänger super-schnell verwenden kann, womit man man aber als Fortgeschrittener nicht sinnvoll arbeiten kann. Bzw. einfach nicht will, weil es ein unlogisches, unübersichtliches & grausames Etwas geworden ist.

ps: Wenn man jeden Stolperstein für Anfänger den eine Sprache bietet entfernt, dann kommt vermutlich 'was raus was man als Anfänger super-schnell verwenden kann, womit man man aber als Fortgeschrittener nicht sinnvoll arbeiten kann. Bzw. einfach nicht will, weil es ein unlogisches, unübersichtliches & grausames Etwas geworden ist.

Klingt wie eine sehr subtile Anspielung