Здравствуйте, 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 с кодом логики.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)