Захват переменной лямбда-функцией

Почему-то выдается ошибка
ошибка: C3480: 'MainWindow::_mServer': a lambda capture variable must be from an enclosing function scope
ошибка: C2440: '<function-style-cast>' : cannot convert from 'OpticsServer' to 'MainWindow::{ctor}::<lambda_90136c7191c 19b81ae18946b77b46459>'
No constructor could take the source type, or constructor overload resolution was ambiguous
ошибка: C2228: left of '.init' must have class/struct/union
type is 'const int'
ошибка: C2065: '_portNumber' : undeclared identifier


_portNumber объявлено

0

Сообщение от Wyn А вы подумали, что в данном случае будет представлять из себя _mServer на стороне лямбды?

Что вы хотите этим сказать? Есть вопрос - спрашивайте.

Сообщение от Wyn Разве нет?

В данном случае аналогично. Что это меняет в контексте поставленной задачи?

0

Сообщение от S_el Что вы хотите этим сказать? Есть вопрос - спрашивайте.

У него там переменная класса с названием Server. У него скорее всего нет конструктора копирования. Но даже если есть, то вряд ли будет хорошей идеей его копировать.
Согласен, можно использовать данный механизм, сохраняя ссылку или указатель, но тут я не вижу ни единой причины использовать его вместо захвата this.

0

Сообщение от Wyn У него скорее всего нет конструктора копирования.

Если нету - компилятор предоставит по умолчанию, если не определен перемещающий конструктор.

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

Потенциально безопаснее( как в смысле получения висячего указателя так и в смысле работы с данными по значению вместо ссылки). Кстати в C++17 должны добавить возможность захвата *this по значению.

1

Сообщение от S_el Если нету - компилятор предоставит по умолчанию, если не определен перемещающий конструктор.

Нет. Под "нету конструктора копирования" я имею в виду, что у элемента нет конструктора копирования. В Qt у подобных элементов обычно стоит макрос с красноречивым именем Q_DISABLE_COPY.

Сообщение от S_el Потенциально безопаснее( как в смысле получения висячего указателя так и в смысле работы с данными по значению вместо ссылки). Кстати в C++17 должны добавить возможность захвата *this по значению.

Поподробнее, если не сложно.
Чем подобный подход "потенциально безопаснее" в контексте задачи? Давайте по пунктам:
1) У человека присутствует переменная-член класса, которую он хочет захватить. В случае если что-то случится с классом - данную переменную постигнет та же участь. Смысл городить огород, отдельно вычленять адрес переменной(в случае если по ссылке) и подключать с++14?
2) Класс называется Server. Учитывая такое название совсем не понятен смысл в его копировании, даже если оно возможно.
3) Захваченные по значению объекты в контексте лямбды - это const(read-only) объекты. Вы в своей жизни хоть раз видали const функцию init? Я тоже нет. Да и зачем ему там скопированный константный класс?
Вот в чём тут потенциальная выгода?

Захват (*this) по значению? То есть копирование класса и использование const копии как this? А смысл? Или как? Честно скажу, это не смотрел и не знаю, что там такого интересного в данной возможности.

1

Сообщение от Wyn Нет. Под "нету конструктора копирования" я имею в виду, что у элемента нет конструктора копирования. В Qt у подобных элементов обычно стоит макрос с красноречивым именем Q_DISABLE_COPY.

Qt в этом вопросе отличается от обычного C++? Удивили, не знал.

Сообщение от Wyn Захваченные по значению объекты в контексте лямбды - это const(read-only) объекты.

не всегда. Вы можете указать спецификатор mutable

Сообщение от Wyn Чем подобный подход "потенциально безопаснее" в контексте задачи?

В контексте задачи важен 2-ой аргумент. Вы, наверняка, знаете, что код обработчика может дописываться/переписываться. Учитывая, что вместо this->m_name компиляторы позволяют писать просто m_name - легко ошибиться, внести изменения и получить не то, что ожидали.

Сообщение от Wyn Класс называется Server. Учитывая такое название совсем не понятен смысл в его копировании, даже если оно возможно.

По приведенному куску кода нельзя ничего сказать о назначении. Тем более вы упускаете кое-что важное. Вопрос, на который я отвечал, звучал так - можно ли захватить переменную член отдельно от this. Я на него дал ответ. Хотите рассмотреть преимущества/недостатки и причины появления такой возможности - создавайте отдельную тему, будем обсуждать, буду рад узнать что-то новое.
Что лучше для задачи без её постановки сказать нельзя. Заниматься додумыванием исходя из названия переменных я не собираюсь.

Сообщение от Wyn Вот в чём тут потенциальная выгода?

Потенциальная выгода не словить ошибку в дальнейшем, а сразу приучатся писать более безопасный код.

Сообщение от Wyn Захват (*this) по значению?

Именно. Подробнее читай здесь.

0

Сообщение от S_el Qt в этом вопросе отличается от обычного C++? Удивили, не знал.

Что вас в моём пояснении удивило?

Сообщение от S_el В контексте задачи важен 2-ой аргумент. Вы, наверняка, знаете, что код обработчика может дописываться/переписываться. Учитывая, что вместо this->m_name компиляторы позволяют писать просто m_name - легко ошибиться, внести изменения и получить не то, что ожидали.

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

Сообщение от S_el Вопрос, на который я отвечал, звучал так - можно ли захватить переменную член отдельно от this.

Понятно. Тогда да, обсуждение лучше завершить, ибо я рассматривал ваш совет в контексте первого поста топикстартера и общего окружения Qt.

0

Сообщение от Wyn Что вас в моём пояснении удивило?

Не сразу правильно прочитал. Не знал, что макрос Q_DISABLE_COPY подавляет генерацию специальных функций-членов.

0

Сообщение от S_el Qt в этом вопросе отличается от обычного C++?

Не отличается.
Раз, два.

0

0