Здравствуйте.

Есть ли сейчас стандартный функциональный объект с одним полем?
Хочется улучшить код. Он работает, но мне не нравится то, что параметр this путешествует по всей цепочке вызовов, хотя используется только в конце, как wnd, где и без того известен.
Заводить переменную уровня модуля не очень интересно, хотя текст короче будет.
Свой тип городить для этого тоже не хочется, короче не выйдет.

Есть обработчик в главном окне, его задача показать историю использования файлов, такой:



У класса истории есть внутренний класс диалога, который запускается модально:




В диалоге есть кнопка Открыть, по нажатию которой надо запустить метод MyFrame::OpenFile:




Хотелось бы чего-то наподобие:



Но я не знаю какой класс использовать как functional_object_with_1_field
и что написать в качестве
const std::unknown_function_object_class_with_1_field<void(const wstring&)>& onOpenReactor
в void History::ShowHistory и в конструкторе диалога и соответственно в мембере

Siemarglteo609,

так передай в свою лямбду параметр

Смысл вопроса в том, чтобы убрать параметр, который уже передается, с сокращением общего количества кода.



Здесь в лямбду приходит параметр wnd, который не что иное как this в том же вызове

И даже по смыслу, задача этой лямбды открыть файл, для чего использовать метод этого же класса.



Для открытия файла нужно только его имя, которое берется из диалога, который открывается из метода другого класса.
И в методе


в описании реактора параметр wxWindow * не нужен ни за чем, кроме как затем, чтобы он добрался до лямбды.
Таких описаний реактора еще два, в мембере диалога и в его конструкторе, а вызывается реактор, он же лямбда, по кнопке диалога Открыть .
И нигде в этих типах лямбд указатель wxWindow *wnd, который будет использоваться только как frame->, по логике программы не нужен, поэтому и хочется его убрать.

Пока я придумал два пути решения:
а) переменную уровня модуля, что будет короче, но не канонично как-то;
б) сделать свой класс с мембером, но тогда общее количество кода не уменьшится, что тоже плохо.

Если бы функциональный объект с одним полем был бы в std, он бы здесь пригодился.
А так пока идет к тому что пойду на вариант а), так меньше кода изучать при сопровождении.

Сорри за повтор, но похоже в исходном комменте я недостаточно ясно описал вопрос.

Siemargl,

Спасибо, это то что нужно.