例:
#include <functional>
int main() {
auto test = []{};
test = []{};
return 0;
}
これにより、gcc 4.7.2 で次のエラー メッセージが出力されます。
test.cpp: In function ‘int main()’:
test.cpp:5:13: error: no match for ‘operator=’ in ‘test = <lambda closure object>main()::<lambda()>{}’
test.cpp:5:13: note: candidate is:
test.cpp:4:16: note: main()::<lambda()>& main()::<lambda()>::operator=(const main()::<lambda()>&) <deleted>
test.cpp:4:16: note: no known conversion for argument 1 from ‘main()::<lambda()>’ to ‘const main()::<lambda()>&’
標準 5.1.2.3 から (強調鉱山):
実装は、変更以外にプログラムの観察可能な動作を変更しないという条件で、以下で説明するものとは異なるクロージャ タイプを定義することができます。
— クロージャータイプのサイズおよび/または配置、
— クロージャー型が自明にコピー可能かどうか(第 9 節)
— クロージャータイプが標準レイアウトクラス (条項 9) であるかどうか、または
— クロージャータイプが POD クラスであるかどうか (条項 9)。
私が知る限り、これは私が直面しているものです。削除された代入演算子を使用しようとして失敗しています。簡単な回避策があるかどうか、さらに広く言えば、一般的にラムダでコピーの構成可能性を省略できるようにする動機となる論理的根拠が何であるかを知りたいです。