Здравствуйте, barney, Вы писали:

B>Исходные условия:
B>Все объекты, связанные с UI — например ViewController, или виджеты типа View, Button, Slider — хранятся в дереве оконной иерархии по shared_ptr.
B>Контроллер — корневой объект иерархии — создает свое корневое окно и сильно владеет им, в окне — размещаются главные зоны, которые размещают свои дочерние виджеты и тд.
B>(Дети в иерархии могут ссылаться обратно на родителей по weak_ptr, если нужно)

Умные указатели только повышают требования к уму программиста, а не заменяют последний. Лично я их не люблю, хотя это индивидуально.

B>Второй вопрос, а что если где то другой воркер полезет в label.setText()
B>не защищать же сам метод мьютексом что приведет к простою воркеров.
B>Значит нужен отдельный вид dispatch для main thread который будет их складывать в очередь и выгребать серийно,
B>например в начале очередного цикла обработки сообщений (runloop)

Мьютексы для GUI в данном случае не затормозят приложение, т.к. пренебрежимо быстры по сравнению с кодом label — ты хочешь экономить на спичках и усложнять код.

B>Лямбды, которые захватывают слишком много могут быть тяжеловесными,
B>возникает вопрос — как эффективнее их хранить
B>Ведь бывает нужно захватить не только weak_ptr, а несколько других связанных объектов UI, текущую открытую базу, текущий сетевой запрос и тд
B>Т.к синглтоны в примере — для простоты, в реальной аппке там будет довольно длинный капчер полноценных объектов / их shared_ptr

Лямбды тоже пренебрежимы для быстродействия в данном случае по сравнению с обменом по сети и GUI. Только я бы использовал более абстрактные функции worker-а в лямбдах, чтобы не смешивать код gui с кодом логики.

Здравствуйте, barney, Вы писали:

B>Исходные условия:
B>Все объекты, связанные с UI — например ViewController, или виджеты типа View, Button, Slider — хранятся в дереве оконной иерархии по shared_ptr.
B>Контроллер — корневой объект иерархии — создает свое корневое окно и сильно владеет им, в окне — размещаются главные зоны, которые размещают свои дочерние виджеты и тд.
B>(Дети в иерархии могут ссылаться обратно на родителей по weak_ptr, если нужно)

Умные указатели только повышают требования к уму программиста, а не заменяют последний. Лично я их не люблю, хотя это индивидуально.

B>Второй вопрос, а что если где то другой воркер полезет в label.setText()
B>не защищать же сам метод мьютексом что приведет к простою воркеров.
B>Значит нужен отдельный вид dispatch для main thread который будет их складывать в очередь и выгребать серийно,
B>например в начале очередного цикла обработки сообщений (runloop)

Мьютексы для GUI в данном случае не затормозят приложение, т.к. пренебрежимо быстры по сравнению с кодом label — ты хочешь экономить на спичках и усложнять код. Если label вообще сам по себе не потокобезопасный.

B>Лямбды, которые захватывают слишком много могут быть тяжеловесными,
B>возникает вопрос — как эффективнее их хранить
B>Ведь бывает нужно захватить не только weak_ptr, а несколько других связанных объектов UI, текущую открытую базу, текущий сетевой запрос и тд
B>Т.к синглтоны в примере — для простоты, в реальной аппке там будет довольно длинный капчер полноценных объектов / их shared_ptr

Лямбды тоже пренебрежимы для быстродействия в данном случае по сравнению с обменом по сети и GUI. Только я бы использовал более абстрактные функции worker-а в лямбдах, чтобы не смешивать код gui с кодом логики.