Betrachten Sie den folgenden Codeausschnitt:

auto f = [](int x) { std::cout << x; };
auto it = boost::make_function_output_iterator(f);
decltype(it) it2 = it;  // Ok, copied
it2 = it;  // Does not compile, cannot assign!

Das Problem ist,function_output_iteratoruf diese Weise konstruiertes @ ist nicht zuweisbar und erfüllt somit nicht das Iterator -Konzept, für das der Typ @ sein mu CopyAssignable.

Dies ist kein Fehler, daboost Function Output Iterator Dokumentation deutlich sagt:

UnaryFunction muss zuweisbar und Copy Constructible sein.

Während der Zuweisung Operator eines Lambda-Funktion ist gelöscht

ClosureType& operator=(const ClosureType&) = delete;

So ist dieses Verhalten technisch korrekt, aber für mich ist es etwas unerwartet. Ich denke, es ist ein vollkommen vernünftiger Wunsch, @ zu konstruierfunction_output_iterator bei einem durch die Lambda-Funktion erzeugten Verschluss. Es erscheint mir unbequem, warum dieser Anwendungsfall ein Problem verursacht.

Hm, ok, dieser StackOverflow, also muss ich eine Frage stellen :) Hier ist es: Wie kann man das umgehen? So erhalten Sie einen korrekten Iterator bei einem Abschluss, der sich wie @ verhäfunction_output_iterator?

Und noch eine: Lohnt es sich, einen Vorschlag zu machen oder einen Bug-Report zu erstellen?