Название: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 15, 2015, 19:21 В системе сигнал-слот нужно обеспечить защищённый вызов сигнала. Т.е. вызвать сигнал может только класс, в котором этот сигнал задан, и его потомки. И метод вызова сигнала должен быть protected, а не public, чтобы кто угодно не мог вызвать сигнал "снаружи".
Пример на Qt: Код
В СигналСлотах Qt творится магия. Там по исходному тексту программы хорошо проходится moc, который творит волшебство с "ключевыми словами" signal, slot, emit. Влезть в эти магические действия, и что-то изменить под свои требования, постороннему вряд ли удастся :). Посему интересует вариант с СигналСлотами Boost'а. Сам Boost'ом не владею, поэтому прошу знатоков показать, как будет выглядеть аналог вышеприведённого примера для Boost.Signals2 :). Т.е. тот же самый набор сигналов и слотов в полном объеме и с наследованием. Сами сигналы публичные, подключиться и отключиться от них может кто угодно. Только чтобы вызов сигнала (emit) был protected и "снаружи" никто не мог вызвать сигнал. Чтобы поменьше писать ручками, шаблонизация 80-го уровня вполне приветствуется, а вот макросов желательно избегать. Хотя вариант с макросами тоже интересен для сравнения :). Вариант на Boost.Signals2, естественно, только с использованием Boost и std. Без Qt, QObject, Q_OBJECT и т.п. :) Так же возможна демонстрация подобной задачи с использованием других библиотек SignalSlot. Интересно посмотреть, как там такое реализовано. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 15, 2015, 21:13 А если в ChildQtShape добавить, например,
Код: protected: И если не секрет - для чего вообще такое понадобилось? Вообще-то нетипичное применение эмита, имхо... Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 11:34 Код: protected: Даже если такое написать, как это изменит тот факт, что любой, у кого есть ссылка на объект shape, может от его имени и без его ведома рассылать сигналы об изменении его состояния, которое на самом деле не менялось, с помощью: Код: // Invalid usage. emit must be protected. Понадобилось это затем, что сигналы об изменении своего состояния должен рассылать только тот объект, который управляет этим своим состоянием. А не любой мимо проходящий :). Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 16, 2015, 12:24 Несколько причудливый запрос :) Понял так: если "signals" не писать, то не будет "мокирования", а signals просто-напросто public.
Все же решение "вообще сменить схему слот-сигнал" выглядит легковесным. Обычно если за плечами уже работающий код, такой путь отвергается сразу. Может простенько спрятать сигнал в унаследованном классе ? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: qate от Октябрь 16, 2015, 12:57 В системе сигнал-слот нужно обеспечить защищённый вызов сигнала. сверху написать комментарий: !!! не вызывать из других классов !!! Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 13:01 Код: // Invalid usage. emit must be protected. Насколько я помню, signals == protected. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 16, 2015, 13:12 Система сигнал слотов в своей основе имеет утверждение - сигнал любого класса может быть вызван при наличии указателя на этот класс. Тем или иным способом. К примеру можно просто вызвать сигнал QMetaObject::invokeMethod в случае с Qt.
В общем то, что вы хотите это очень сложно и противоречит самой идее :) Разве что написать свою систему сигнал-слотов, только закрытую. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 13:37 А вы это проверяли? Насколько я помню, signals == protected. В том-то и дело, что сначала хотел написать: "Чтобы было как в Qt, emit - protected" :). Потом ради смеха набрал эту причудливую конструкцию, она мало того, что скомпилировалась, так и работает. Поведение поменялось в Qt 5. Signals & Slots Qt 4.8 (http://doc.qt.io/qt-4.8/signalsandslots.html): Цитировать Signals Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Only the class that defines a signal and its subclasses can emit the signal. Signals & Slots Qt 5 (http://doc.qt.io/qt-5/signalsandslots.html): Цитировать Signals Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Signals are public access functions and can be emitted from anywhere, but we recommend to only emit them from the class that defines the signal and its subclasses. Система сигнал слотов в своей основе имеет утверждение - сигнал любого класса может быть вызван при наличии указателя на этот класс. Тем или иным способом. К примеру можно просто вызвать сигнал QMetaObject::invokeMethod в случае с Qt. В общем то, что вы хотите это очень сложно и противоречит самой идее :) Мне вот кажется, что всё совсем наоборот :). Может вы о слотах говорите? Все же решение "вообще сменить схему слот-сигнал" выглядит легковесным. Обычно если за плечами уже работающий код, такой путь отвергается сразу. Может простенько спрятать сигнал в унаследованном классе ? Про "менять схему сигнал-слот" к теме не относится. Мне интересно, как это выглядит в Boost. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 13:51 Мне интересно, как это выглядит в Boost. Сигнал в бусте это объект. Если его убрать из публичной секции, то эмитеть никто не сможет, кроме самого объекта. Но нужно будет добавить публичный метод для организации подключения (connect).Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 14:02 Сигнал в бусте это объект. Если его убрать из публичной секции, то эмитеть никто не сможет, кроме самого объекта. Но нужно будет добавить публичный метод для организации подключения (connect). И для отключения :). Я примерно представил, как это будет, выходит слишком громоздко. Поэтому и спрашиваю знающих людей, может есть способ покороче всё это описать. Можно с применением шаблонов, на крайний случай с макросами. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 15:50 Ну вот что получилось по быстрому:
Код
Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 17:06 Ну вот что получилось по быстрому: ... Вариант с макросами понятен. На макросах можно много чего быстро наваять :). По этому поводу интересно мнение: вы бы стали использовать такой вариант в production в большом проекте? Какие плюсы и минусы видите? Для меня, из плюсов только то, что так можно быстро написать, чтобы опробовать такую схему применения. Минусы: 1. Мне никогда не нравились такие куски кода в макросах. (Пусть это будет личное, субъективное :) ) 2. Макрос меняет уровень доступа. В примере m_##name расположен в private, хотя надо бы protected, чтобы дочерние классы могли сигналить. Кто-нибудь может забыть после protected написать private, и разрешит защищённый доступ к приватным данным. Может и мелочь, но всё же. 3. Методы типа connect_xxx() нельзя назвать универсальными. Они плохо поддаются дальнейшей обработке макросами, специализациями шаблонов. 4. Если появится "хотелка", чтобы сигналы объявлялись в одном месте (интерфейс, абстрактный базовый класс), а фактически m_##name располагалась в другом классе (реализации). Как быть? (На этот пункт пока не стоит обращать особого внимания) 5. Остальные минусы, присущие макросам в целом. Boost же ценится шаблонизацией 90-го уровня :). На шаблонах такое можно красиво сделать, с минимумом использования макросов? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 16, 2015, 17:48 Понадобилось это затем, что сигналы об изменении своего состояния должен рассылать только тот объект, который управляет этим своим состоянием. А не любой мимо проходящий :). Просто чтобы понять... Вы хотите предотвратить взлом системы? Цитировать По этому поводу интересно мнение: вы бы стали использовать такой вариант в production в большом проекте? Нет, ибо чукча - не всегда писатель, но иногда и читатель :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 16, 2015, 17:51 Цитировать На шаблонах такое можно красиво сделать, с минимумом использования макросов? Вообще можно, но из-за двух методов connect/disconnect может и не стоит.. Но как вариант: Код
Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 17:52 Нет, ибо чукча - не всегда писатель, но иногда и читатель :) Господи, а что плохо читается в этом? :)Код
Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 16, 2015, 18:05 вы бы стали использовать такой вариант в production в большом проекте? Какие плюсы и минусы видите? В большом проекте давно решено какие слот/сигнал юзать, даже попытки пересмотра этого решения будут стоить очень дорого. Поэтому не надо парить про мифическую защиту, скажите просто "хочу попробовать на бусте" - в этом нет ничего плохого :)Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 16, 2015, 18:15 Нет, ибо чукча - не всегда писатель, но иногда и читатель :) Господи, а что плохо читается в этом? :)Код
Ненативно :) Это мы с вами сейчас понимаем, о чем идет речь, а Раджапраштану из Бангалора может стать не по себе :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 18:22 Просто чтобы понять... Вы хотите предотвратить взлом системы? Это к вопросу инкапсуляции, и необходимости Приватных методов (http://www.prog.org.ru/topic_29328_0.html), обсуждение которых было таким бурным :). А может и правда, чего нам скрывать? И дать возможность сигналить от нашего имени всем, кому не лень :). Вообще можно, но из-за двух методов connect/disconnect может и не стоит.. Но как вариант: ... Этот вариант мне нравится значительно больше. Хотя я не фанат дружбы friend. Кстати, почему не стоит? И как тогда стоит? :) В большом проекте давно решено какие слот/сигнал юзать, даже попытки пересмотра этого решения будут стоить очень дорого. Поэтому не надо парить про мифическую защиту, скажите просто "хочу попробовать на бусте" - в этом нет ничего плохого :) Я интереса "хочу попробовать на бусте" вроде как изначально и не скрывал :). Нужна эта "мифическая защита" или нет, меня тоже интересует, и мнения по этому поводу. А так же есть ли такая система сигнал-слот, которая отвечает канонам ООП.Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 18:33 Ненативно :) Ну конечно, Q_OBJECT нативненько, а это не нативненько. :)Это мы с вами сейчас понимаем, о чем идет речь, а Раджапраштану из Бангалора может стать не по себе :) Все документируется и даже последний индус все поймет. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 19:03 А так же есть ли такая система сигнал-слот, которая отвечает канонам ООП. До введения нового формата коннекта отвечала Qtшная. :)Мне кажется, что на чистом С++ без moc такое сделать будет не легко, если вообще возможно. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 16, 2015, 19:24 Цитировать Кстати, почему не стоит? И как тогда стоит? Ну не знаю) У меня нет универсального рецепта) Это уже вы сами решайте)Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 19:35 До введения нового формата коннекта отвечала Qtшная. :) Мне кажется, что на чистом С++ без moc такое сделать будет не легко, если вообще возможно. Ну не знаю) У меня нет универсального рецепта) Это уже вы сами решайте) Хорошо. Тогда акцент на то, нужно ли вообще вызов сигналов прятать? Или это желание из разряда: "Ишь чего захотел!"? :) Или, если с этим прятаньем так много возни и трудно реализовать, то и фиг с ней, инкапсуляцией? :) Это же сигналы, их в здравом разуме никто же не будет снаружи без причины вызывать. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 19:38 Это же сигналы, их в здравом разуме никто же не будет снаружи без причины вызывать. this.Защита в С++ сделана как защита от ошибок, а не как защита от злоумышленника. Если кому-то понадобиться, то он легко сможет вызывать и приватные методы. :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 16, 2015, 19:42 При желании можно просто не выдавать указатель на объект с сигналами. Тогда никто его и трогать не будет.
Хотя как правильно заметили, при желании можно вообще откуда угодно вызвать :D Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 16, 2015, 19:55 Защита в С++ сделана как защита от ошибок, а не как защита от злоумышленника. Если кому-то понадобиться, то он легко сможет вызывать и приватные методы. :) Со злоумышленниками понятно, от них не защитишься. А как быть с не очень опытными разработчиками, или теми, кто "сделаю щас быстренько, тут проще самому сигнал вызвать, чем ждать пока он появится"? Следить и по рукам бить? Или это слишком фантастический сценарий: неправильный вызов сигнала, и об этом не стоит беспокоиться? :) При желании можно просто не выдавать указатель на объект с сигналами. Тогда никто его и трогать не будет. Хотя как правильно заметили, при желании можно вообще откуда угодно вызвать :D Если не давать указатель, то и подключиться к нему никто не сможет :). Толку от такого объекта с его сигналами :). Я так понимаю, что в конечном итоге всё сводится к порядочности и разумности разработчиков :D. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 16, 2015, 19:59 Со злоумышленниками понятно, от них не защитишься. А как быть с не очень опытными разработчиками, или теми, кто "сделаю щас быстренько, тут проще самому сигнал вызвать, чем ждать пока он появится"? Следить и по рукам бить? Или это слишком фантастический сценарий: неправильный вызов сигнала, и об этом не стоит беспокоиться? :) Сначала всем сказать, что эмитить сигнал может класс, его содержащий, а потом следить и с чистой совестью бить по рукам. :)Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 16, 2015, 23:13 Сначала всем сказать, что эмитить сигнал может класс, его содержащий, а потом следить и с чистой совестью бить по рукам. :) +1 Хорошо. Тогда акцент на то, нужно ли вообще вызов сигналов прятать? Или это желание из разряда: "Ишь чего захотел!"? :) Или, если с этим прятаньем так много возни и трудно реализовать, то и фиг с ней, инкапсуляцией? :) Это же сигналы, их в здравом разуме никто же не будет снаружи без причины вызывать. Здравый смысл никто не отменял. Если человек будет пытаться сделать подобное - ССЗБ. Тем более, неопытный. Это ж еще ему до этого додуматься надо - вызвать эмит сигнала от имени левого класса :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 01:08 Не отнимайте у юных и убогих возможность выстрелить себе в голову :D
Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 17, 2015, 02:22 Не отнимайте у юных и убогих возможность выстрелить себе в голову :D Ладно бы себе, они ж и другим отстрелить головы могут :D. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 10:57 До сих пор в упор не понимаю, что вам мешает нужные вам сигналы вывести на интерфейсный класс, а свой спрятать внутри. И фиг кто подцепится.
Т.е. пробросить нужные сигналы через интерфейсный, а внутренние не проявлять. И получаем ваши хотелки - класс с сигналами внутри (которые никто не может вызвать, ибо нет доступа к указателю на класс) и с сигналами проброшенными через интерфейсный класс, которые только и сможет вызывать и цеплять программист. PS это же простое использование инкапсуляции - не хошь чтобы рылись в нутрях - дай только интерфейсный класс :D Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 17, 2015, 12:12 Не отнимайте у юных и убогих возможность выстрелить себе в голову :D Ладно бы себе, они ж и другим отстрелить головы могут :D. Ну а что, лучше городить кучу нечитаемого индокода в надежде на то, что он помешает кому-то вызвать какой-то там сигнал ??? Вам не кажется, что сама идея этого уже ненормальна и отдает каким-то... маразмом, что ли? Разрабы Qt ведь тоже не идиоты и для чего-то они не запрещают подобное использование. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 12:14 Разрабы как раз используют предложенный мной метод - внутри интерфейсного класса имеется приватный класс со своими сигналами и механикой, до которого хрен достучишься :)
Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 17, 2015, 12:31 Ну а что, лучше городить кучу нечитаемого индокода в надежде на то, что он помешает кому-то вызвать какой-то там сигнал ??? Вам не кажется, что сама идея этого уже ненормальна и отдает каким-то... маразмом, что ли? Разрабы Qt ведь тоже не идиоты и для чего-то они не запрещают подобное использование. Тему внимательно читали? И документацию Qt? См. ответ #7 (http://www.prog.org.ru/index.php?topic=29431.msg216226#msg216226). До сих пор в упор не понимаю, что вам мешает нужные вам сигналы вывести на интерфейсный класс, а свой спрятать внутри. И фиг кто подцепится. Т.е. пробросить нужные сигналы через интерфейсный, а внутренние не проявлять. И получаем ваши хотелки - класс с сигналами внутри (которые никто не может вызвать, ибо нет доступа к указателю на класс) и с сигналами проброшенными через интерфейсный класс, которые только и сможет вызывать и цеплять программист. PS это же простое использование инкапсуляции - не хошь чтобы рылись в нутрях - дай только интерфейсный класс :D В моём первом сообщении задача вроде поставлена достаточно конкретно :). Для того примера можете написать "интерфейсный" класс и "свой"? Хоть на Qt, хоть на бусте хоть на чём :). Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 17, 2015, 13:06 В моём первом сообщении задача вроде поставлена достаточно конкретно :). Для того примера можете написать "интерфейсный" класс и "свой"? Хоть на Qt, хоть на бусте хоть на чём :). Ну как же... если нет моментального ответа (лучше цитата букваря) - это автоматычно означает что Вы не умеете поставить задачу :) Ладно, на бусте так на бусте. Ну а почему бы не открыть доку буста, взять тамошний пример слот/сигнал и сделать по образцу. А примеры там есть (помню). В чем проблема и что собственно обсуждать? И заодно подумать много ли в этом творчества (или крутизны) - ну ведь очередное лакание хелпа, только из др ведра :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 17, 2015, 13:49 это автоматычно означает что Вы не умеете поставить задачу :) и это говорит король постановки задач... ;D P.S. Простите, не удержался. :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 17:01 Перечитал темку - вы требуете невозможного.
Сокрыть сигнал, который должен быть открытым для оповещения и подключения. Да, вы хотите запретить вызов сторонним объектом, но сигнал НЕ ЯВЛЯЕТСЯ полем класса. Сигнал по сути это описание в менеджере сигнал слотовой системы. Чтобы изменить работу сигнала, надо менять сигнал слотовую систему или написать свою. Идея интересная, но бессмысленная. Дурак никогда до такого не додумается. А умный и так знает, что если самому вызывать фиг пойми какие сигналы с произвольными аргументами, программа фиг знает что будет делать. Я б посоветовал написать в комментариях "Произвольный вызов сигналов ведёт к непредсказуемому поведению класса" и потом дураков-умников, которые так сделают, тыкать туда носом :D PS наглядный пример - сам Qt. Ещё никому не удавалось додуматься до вызова сигнала объекта с произвольными параметрами. Вы можно сказать первооткрыватель :D Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 17, 2015, 17:29 Цитировать Перечитал темку - вы требуете невозможного. Да ну ладно?) Цитировать Сокрыть сигнал, который должен быть открытым для оповещения и подключения. Не совсем так.. Вполне понятна и естественна ситуация, когда (внутренняя) логика класса знает в каких случаях эмитить сигнал, и не хочет чтобы на этот процесс влиял кто-либо извне, но, с друнгой стороны, предоставитиь возможность этой самой другой стороне подписываться на этот сигнал, то это нормальное законное желание. Не противоречащее канонам ООП и философии C++ в частности) Да, вы хотите запретить вызов сторонним объектом, но сигнал НЕ ЯВЛЯЕТСЯ полем класса. Сигнал по сути это описание в менеджере сигнал слотовой системы. igors, проверьте, я там всё без ошибок (орфографических и пунктуационных) написал? :) Цитировать PS наглядный пример - сам Qt. Ещё никому не удавалось додуматься до вызова сигнала объекта с произвольными параметрами. Вы можно сказать первооткрыватель А это здесь вообще причём? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 17, 2015, 18:06 Не совсем так.. Вполне понятна и естественна ситуация, когда (внутренняя) логика класса знает в каких случаях эмитить сигнал, и не хочет чтобы на этот процесс влиял кто-либо извне, но, с друнгой стороны, предоставитиь возможность этой самой другой стороне подписываться на этот сигнал, то это нормальное законное желание. Не противоречащее канонам ООП и философии C++ в частности) Ох ты ж боже ж мой - "(внутренняя) логика класса", "каноны", "философия"... Все это (очень) часто - визитная карточка бездельника. Нету главного - предметной части, уж слишком охотно клюет на "чистую абс(т)ракцию". Вот тут задача поставлена прекрасно - ведь можно купаться в идеологии и ни за что не отвечать. А напр здесь (http://www.prog.org.ru/index.php?topic=29435.msg216262#msg216262) - ну опять полная безграмотность :)igors, проверьте, я там всё без ошибок (орфографических и пунктуационных) написал? :) 2 запятые не на месте. 2 раза описАлись. И мой ник пишется с большой буквы. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 17, 2015, 18:14 А напр здесь (http://www.prog.org.ru/index.php?topic=29435.msg216262#msg216262) - ну опять полная безграмотность :) Даааа, не идет народ в ваши темы, не идет. Даже не смотря на то, что вопросы вы поднимаете простенькие и уверен многие бы с удовольствием поучаствовали в их обсуждении. Хамство в купе с высокомерием делают свое дело. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 18:58 Наглядный пример Qt. Вы можете тем же способом что и привели в 1 сообщении данной темы испоганить ВСЁ, начиная от QObject и заканчивая QWebView.
Просто отсылая от имён стандартных виджетов сигналы. Но почему то ни 1 темы нет - это плохо работает, я посылаю сигнал destroyed от mainWindow и у меня падает программа. Почему нет таких тем? Потому что никому такое не нужно и все понимают, что если засунуть в работающий движок машины руку, то либо рука нафиг, либо мотор. (хотя чаще рука :D) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 17, 2015, 19:17 Сокрыть сигнал, который должен быть открытым для оповещения и подключения. Да, вы хотите запретить вызов сторонним объектом, но сигнал НЕ ЯВЛЯЕТСЯ полем класса. Сигнал по сути это описание в менеджере сигнал слотовой системы. Интересное мнение о системе сигнал-слот :). Но рациональное зерно есть. С позволения m_ax, приведу кусок его кода: Код
В этом примере signal<>::m_sig и Demo::my_signal чем являются для класса? Или это не сигналы? Ещё раз процитирую документацию Qt: Цитировать Signals are public access functions and can be emitted from anywhere, but we recommend to only emit them from the class that defines the signal and its subclasses. Собственно, в примере из первого сообщения можно было написать просто: Код Т.е. "сигнал" в Qt - это публичный метод. В обоих случаях термин "описание в менеджере сигнал слотовой системы" не раскрывается :). За магией трудно проследить реальное положение вещей. Допустим есть пара методов: Код Велика ли вероятность ошибочного вызова shape.moved(x, y)? Со всеми этими "code completion" в редакторе, можно же просто промазать. Когда в запарке что-то быстро пишется, текст программы уже сливается, глаз замылился. Или все разработчики всегда собраны, всегда всё за собой проверяют, читают документацию? :) Наглядный пример Qt. Вы можете тем же способом что и привели в 1 сообщении данной темы испоганить ВСЁ, начиная от QObject и заканчивая QWebView. Просто отсылая от имён стандартных виджетов сигналы. Но почему то ни 1 темы нет - это плохо работает, я посылаю сигнал destroyed от mainWindow и у меня падает программа. Почему нет таких тем? Потому что никому такое не нужно и все понимают, что если засунуть в работающий движок машины руку, то либо рука нафиг, либо мотор. (хотя чаще рука :D) В Qt 4.x emit сигналов был protected. Потому таких тем и не было. Приучили к хорошему. А с Qt 5 не все знают, что теперь они публичные. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 19:51 ViTech, invokeMethod позволяет с версии 4.7 ТОЧНО (а по логике и ранее) вызвать любой сигнал и/или слот объекта, имея на него указатель :D
То, что написал ТС просто недокументированная возможность, но вкупе с ней спокойно можно написать QMetaObject::invokeMethod(point, "slot/signal"). И это официальная и документированная возможность. Работает в 4.7 и в 5.5 Система сигнал слот включается в себя и moc. Который просто пробегается по всем signals/emit и прочим и уже на основании этих описаний строит код :) Разве что я был неточным, это описание в сигнал слотовой системе, а не в менеджере сигнал слотовой системы :) PS PPS да, спокойно вызываем любой сигнал/слот при наличии указателя :D Было б желание, а испортить мы сумеем :) PPPS собственно этим и было вызвано моё удивление - сама система позволяет это сделать официально, а ТС в ужасе от таких возможностей :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 17, 2015, 20:13 Цитировать 2 запятые не на месте. 2 раза описАлись. И мой ник пишется с большой буквы. Прошу прощения за ошибки) Это всё виноват товарищ Racheengel .. Накаркал тогда про мою хрестоматийную минималистичную клавиатуру, и через пару дней на неё вылили бокал вина(( Вот теперь сижу с мультимедийной, такой непривычной.. По клавишам клянцаю с таким усилием..(Цитировать invokeMethod позволяет с версии 4.7 ТОЧНО (а по логике и ранее) вызвать любой сигнал и/или слот объекта, имея на него указатель А invokeMethod, по вашему соответствует ли идеологии ООП в контексте сигнал/слотов?Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 20:17 Система сигнал слотов рвёт ООП в сторону удобства :D И это выгодный размен, как показало время :)
Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 17, 2015, 20:19 Система сигнал слотов рвёт ООП в сторону удобства :D И это выгодный размен, как показало время :) Значит всё-таки не соответствует? А теперь ещё раз перечитайте тему) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 17, 2015, 20:21 Код
Таким макаром можно официально и приватные методы вызывать :). И да, я в ужасе от таких возможностей. О чём это говорит? О том, что они специально так сделали, чтобы защищённые методы вызывать, или просто не стали в мета-информацию закладывать уровни доступа? Почему тогда они стесняются пойти дальше и в той же версии Qt 4.x пишут: Код: Only the class that defines a signal and its subclasses can emit the signal. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Old от Октябрь 17, 2015, 20:37 О том, что они специально так сделали, чтобы защищённые методы вызывать, или просто не стали в мета-информацию закладывать уровни доступа? Если закладывать уровни доступа, то их нужно проверять в runtime. Каждый вызов слота должен проверяться. А чего добиваемся? Пытаемся дублировать уровни доступа языка, которые проверяются в compiletime?Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 17, 2015, 20:52 Если закладывать уровни доступа, то их нужно проверять в runtime. Каждый вызов слота должен проверяться. А чего добиваемся? Пытаемся дублировать уровни доступа языка, которые проверяются в compiletime? Так я о том и спрашиваю :). Я не знаю, чем руководствовались разработчики, позволяя через invokeMethod вызывать защищённые методы. Стоит к invokeMethod относиться как к "официальной возможности", или всё же эта штука больше нужна для внутренних потребностей Qt? И раз она такая полезная оказалась, то дали возможность её всем пользоваться, взамен ожидая осторожности, поскольку она нарушает инкапсуляцию. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 17, 2015, 21:22 Qt развивается в сторону удобства разработчиков. Да, попираются стандарты, да, возможны отходы в сторону неоптимальных и "неправильных" в ООП вещах.
Но это удобно :) to m_ax: пролетел темку, не нашёл места где идёт переход с "хочу сделать так", на "должно соответствовать ООП" :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 18, 2015, 02:20 Цитировать to m_ax: пролетел темку, не нашёл места где идёт переход с "хочу сделать так", на "должно соответствовать ООП" Ну как же, первый пост:Цитировать Т.е. тот же самый набор сигналов и слотов в полном объеме и с наследованием. Сами сигналы публичные, подключиться и отключиться от них может кто угодно. Только чтобы вызов сигнала (emit) был protected и "снаружи" никто не мог вызвать сигнал. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 18, 2015, 04:43 Допустим есть пара методов: К сожалению да, такая вероятность велика. Я часто влетаю на аналогичном normalize/normalized. Но это никак не связано с слот/сигнал.Код Велика ли вероятность ошибочного вызова shape.moved(x, y)? Со всеми этими "code completion" в редакторе, можно же просто промазать. Когда в запарке что-то быстро пишется, текст программы уже сливается, глаз замылился. Или все разработчики всегда собраны, всегда всё за собой проверяют, читают документацию? :) Так что там с бустом, разобрались? Да, я видел пример m_ax, но как-то.. сходу непонятно, а вникать нет необходимости. Почти наверняка бустовская реализация "профессиональнее", но в Qt на нем навешаны вкуснейшие плюшки. Напр легким движением руки (QueuedConnection) сигнал превращается в элегантное событие. Хотя бы ради этого можно и потерпеть гнусное "мокирование", а о такой мелочи как public неудобно и говорить Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 18, 2015, 13:00 Так что там с бустом, разобрались? Да, я видел пример m_ax, но как-то.. сходу непонятно, а вникать нет необходимости. Почти наверняка бустовская реализация "профессиональнее", но в Qt на нем навешаны вкуснейшие плюшки. Напр легким движением руки (QueuedConnection) сигнал превращается в элегантное событие. Хотя бы ради этого можно и потерпеть гнусное "мокирование", а о такой мелочи как public неудобно и говорить Конечно, большие минусы сигнал-слотов Qt явно не в том, что в 5-ой версии emit вдруг стал публичным :). Всё слишком завязано на инфраструктуру Qt в общем (что не удивительно), и на QObject в частности. Не всем и не всегда охота наследоваться от QObject или таскать его с собой, чтобы рассылать сигналы. Поэтому стало интересно, как обстоят дела в других системах сигнал-слот. Ради одного сигнала из буста я бы не стал такой огород городить. Всё тривиально и в документации расписано. А вот как это использовать в более-менее большом проекте, который ещё хочет следовать "канонам ООП" :). Поэтому и говорил о "полном наборе сигналов и наследовании". Вариант (http://www.prog.org.ru/index.php?topic=29431.msg216231#msg216231) Old работает "здесь и сейчас", но в длительной перспективе использования мне он не очень нравится, и я писал почему. Вариант (http://www.prog.org.ru/index.php?topic=29431.msg216236#msg216236) m_ax мне нравится больше, но дружба дружбой, а сигналы врозь :). Требование по наследованию не выполняется. Потомки Demo не смогут вызвать родительский my_signal. В конечном итоге хотелось бы такой же лёгкости и краткости в описании сигналов, как в Qt :). Вот и стало интересно, насколько это реально с использованием сигналов буста. Пусть даже и с шаблонизацией 80-го уровня. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 15:01 Как по мне,
Цитировать А вот как это использовать в более-менее большом проекте, который ещё хочет следовать "канонам ООП" и Цитировать Пусть даже и с шаблонизацией 80-го уровня. это вещи взаимоисключающие. Да, и каким образом модель сигналов-слотов Qt противоречит "канонам ООП"? Это всего лишь способ обмена сообщениями между объектами в системе. Цитировать В конечном итоге хотелось бы такой же лёгкости и краткости в описании сигналов, как в Qt Так ответ в этой вашей фразе :) Просто Используйте Сигналы Qt :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 18, 2015, 15:40 Не всем и не всегда охота наследоваться от QObject или таскать его с собой, чтобы рассылать сигналы. Да, это аргумент. Как говорил ШтирлицЦитировать Вот с этого и надо было начинать Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 17:04 А, так речь о том, чтобы симулировать кутишные сигналы не-кутишными средствами? :)
Я-то был уверен, что автор хочет зарубить вызовы кутишных сигналов, если они не public... Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Bepec от Октябрь 18, 2015, 17:07 Он хочет сигналы с функциональностью Qt, но имеющие защиту от вызова из "посторонних" классов и поддерживающие наследование. Т.е. с защитой доступа.
Пока решения ему не предложили, которое бы удовлетворяло :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 18, 2015, 17:32 Ещё немного, и мне припишут, что я хочу на Марс на боинге долететь :).
А, так речь о том, чтобы симулировать кутишные сигналы не-кутишными средствами? :) Я-то был уверен, что автор хочет зарубить вызовы кутишных сигналов, если они не public... Автор хочет лишь того, что обозначено в первом сообщении. Или хотя бы название темы внимательно прочитайте. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 18:22 Он хочет сигналы с функциональностью Qt, но имеющие защиту от вызова из "посторонних" классов и поддерживающие наследование. Т.е. с защитой доступа. Пока решения ему не предложили, которое бы удовлетворяло :) Написать кутишникам и попросить сделать спецверсию сигналслотов, как вариант ;) Хотя это желание из серии "хочу мерседес с двигателем от Т90"... Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 18:24 Автор хочет лишь того, что обозначено в первом сообщении. Просто от вас народ так и не добился, какая ПРАКТИЧЕСКАЯ НЕОБХОДИМОСТЬ такой штуки... Если просто эксперимента, ну так вариантов немного, и все кривые. Для реальных проектов это не нужно... Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 18, 2015, 19:24 Просто от вас народ так и не добился, какая ПРАКТИЧЕСКАЯ НЕОБХОДИМОСТЬ такой штуки... Если просто эксперимента, ну так вариантов немного, и все кривые. Почему-то Old и m_ax не понадобилось ничего добиваться, чтобы предложить конкретный вариант :). Вы хотя бы какой-нибудь вариант можете предложить, хоть кривой? Может там совсем немного надо подправить, чтобы выпрямить. Для реальных проектов это не нужно... То, что вам в реальных проектах не нужно, другим может понадобиться. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 20:15 Я, вообще-то, в самом первом ответе предложил :)
Сигналы, описанные в секции Q_SIGNALS, не должны являться частью интерфеса. А ту часть интерфейса, которая должна эмитировать сигналы, делаете защищенной. После этого только наследники вашего класса смогут эмитировать нужные сигналы. Все остальное - от лукавого :) Ведь идеологая сигнал-слот в том и состоит, чтобы находиться "сверху" над объектной моделью и обеспечивать коммуникацию между объектами. Разработчика не должна волновать потенциальная возможность эмитирования сигнала из другого класса. Есть много способов сделать что-либо "по другому", но тот, кто пытается микроскопом гвозди забивать - сам себе злобная буратинка :) Как уже говорил Old, документируйте интерфейс не в плане "а вот это делать низя!", а в плане "чтобы эмитировать такой-то сигнал, наследуйтесь от класса и вызовите защищенный метод". Это будет лучшим решением проблемы. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 20:23 Прошу прощения за ошибки) Это всё виноват товарищ Racheengel .. Накаркал тогда про мою хрестоматийную минималистичную клавиатуру, и через пару дней на неё вылили бокал вина(( Вот теперь сижу с мультимедийной, такой непривычной.. Ну вот, пригодился же подарог :) Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 18, 2015, 21:02 Сигналы, описанные в секции Q_SIGNALS, не должны являться частью интерфеса. А ту часть интерфейса, которая должна эмитировать сигналы, делаете защищенной. После этого только наследники вашего класса смогут эмитировать нужные сигналы. Все остальное - от лукавого :) Спасибо, что объяснили :). Получается всё довольно просто :). И даже идеология появилась. А так же интерфейсы, которые уже упоминались в этой теме, но примера я так и не дождался. Конкретно с использованием boost::signals2 такое можно реализовать? Если да, то насколько это просто/сложно. Если нет, то почему? Сигналы буста вписываются в идеологию и интерфейсы? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Racheengel от Октябрь 18, 2015, 21:50 под интерфейсом имеется в виду следующее (вроде, еще Верес про них тоже писал):
Код: class IDoStuff В этом случае через интерфейс IDoStuff можно будет получить доступ извне только к СDoStuff::doSometning(), который внутри может быть имплементирован как на слотах, так и на шаблонах индусского уровня. Никакой emit СDoStuff::someSignal() не пройдет) А если вы отнаследуетесь от CDoStuff, не указывая макрос Q_OBJECT, то не сможете вообще ничего эмитить напрямую. Только через вызов emitSomeSignal(). Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 19, 2015, 04:52 Конкретно с использованием boost::signals2 такое можно реализовать? Если да, то насколько это просто/сложно. Если нет, то почему? Сигналы буста вписываются в идеологию и интерфейсы? Я уже "потерял нить", какое "такое"? :) Под Вашим (тлетворным) влиянием открыл доку (http://www.boost.org/doc/libs/1_59_0/doc/html/signals2/tutorial.html#idp426962304) и прочитал. Ну первые 2 примера попытался осознать (вполне успешно), остальное "ознакомился" (пролистал). Ничего страшного, и очень приятно что для использования просто "подкинуть хедер". Что касается "защищенного вызова" (если разговор еще об этом), то там сигнал - конкретная переменная, ну и прячьте ее обычными средствами языка, какие-то спец средства в самой системе слот/сигнал не нужны. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 19, 2015, 17:46 Я уже "потерял нить", какое "такое"? :) "Такое" описано в цитате двумя строчками выше того моего предложения со словом "такое". А так же, более подробно, в первом сообщении этой темы :). Я не устану на него ссылаться :). Под Вашим (тлетворным) влиянием открыл доку (http://www.boost.org/doc/libs/1_59_0/doc/html/signals2/tutorial.html#idp426962304) и прочитал. Ну первые 2 примера попытался осознать (вполне успешно), остальное "ознакомился" (пролистал). Ничего страшного, и очень приятно что для использования просто "подкинуть хедер". Влияние хоть и тлетворное, зато вы познакомились с сигналами буста, которые вполне приятны в использовании :). Что касается "защищенного вызова" (если разговор еще об этом), то там сигнал - конкретная переменная, ну и прячьте ее обычными средствами языка, какие-то спец средства в самой системе слот/сигнал не нужны. Замечательно :). Теперь спрячьте определение сигнала в разделе protected и обеспечьте возможность подключаться/отключаться к ним любому желающему. Штуки четыре для начала, вида: Цитировать void visibleChanged(bool visible); void enabledChanged(bool enable); void positionChanged(int x, int y); void sizeChanged(int height, int width); под интерфейсом имеется в виду следующее (вроде, еще Верес про них тоже писал): Код: class IDoStuff В этом случае через интерфейс IDoStuff можно будет получить доступ извне только к СDoStuff::doSometning(), который внутри может быть имплементирован как на слотах, так и на шаблонах индусского уровня. Никакой emit СDoStuff::someSignal() не пройдет) А если вы отнаследуетесь от CDoStuff, не указывая макрос Q_OBJECT, то не сможете вообще ничего эмитить напрямую. Только через вызов emitSomeSignal(). Это всё тоже замечательно, но где там слова boost::signals2::signal? Где в интерфейсе IDoStuff методы для подключения и отключения сигналов? Конкретный пример с использованием boost::signals2 можете нарисовать? :) Подробности в этом же сообщении чуть выше, обращённые к Igors. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 19, 2015, 20:09 Цитировать Теперь спрячьте определение сигнала в разделе protected и обеспечьте возможность подключаться/отключаться к ним любому желающему. Штуки четыре для начала, вида: Цитировать void visibleChanged(bool visible); void enabledChanged(bool enable); void positionChanged(int x, int y); void sizeChanged(int height, int width); Вообще и такое, в принципе, возможно реализовать (используя tuple): Код
Ну или то же самое но с X-макросами: Код
Но это так, просто к слову.. Что в принципе возможности это сделать есть.. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 19, 2015, 22:37 Вообще и такое, в принципе, возможно реализовать (используя tuple): Вариант с макросами пока пропустим, а вот на шаблонах интересно :).... Нужно продвинуться дальше, с наследованием. Допустим мы смирились с перечислением индексов сигналов в enum и их определением в tuple. Я правильно понимаю, что эти все connect, disconnect, emit придётся копипастить в каждый класс, где объявляются сигналы? Вариант, что это можно записать в макросы, более короткие и безобидные, пока тоже пропустим. Если бы всё было так просто, то эти шаблонные методы можно было бы вынести в базовый класс, и они бы "распространились" на все дочерние. Эти три метода можно ещё как-то "ушаблонить" чтобы не копипастить? :) Mixin'ом каким, или ещё чем. Например, написать внешние функции connect и disconnect, а для классов с сигналами создать потомков конкретно для заданной функции. Как-то так: Код
При таком использовании Connector и Disconnector есть что-нибудь ужасное с точки зрения концепций ООП :) (я правда, серьёзно спрашиваю), или какие другие подводные камни? Появляются ли накладные расходы по памяти/времени в runtime? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 19, 2015, 22:59 Цитировать Нужно продвинуться дальше, с наследованием. Допустим мы смирились с перечислением индексов сигналов в enum и их определением в tuple. Я правильно понимаю, что эти все connect, disconnect, emit придётся копипастить в каждый класс, где объявляются сигналы? Нет, ну можно назвать класс Demo базовым. Т.е. сейчас можно запросто наследоваться от него и ничего копипастить не нужно, т.е.:Код
Или речь идёт о том, что в наследниках нужно определять дополнительные сигналы (которых нет в базовом)? Цитировать При таком использовании Connector и Disconnector есть что-нибудь ужасное с точки зрения концепций ООП :) (я правда, серьёзно спрашиваю), или какие другие подводные камни? Появляются ли накладные расходы по памяти/времени в runtime? Мне кажется это уже перебор.. И я не совсем понимаю, какой сейчас от них профит? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 19, 2015, 23:28 Или речь идёт о том, что в наследниках нужно определять дополнительные сигналы (которых нет в базовом)? Да, в наследниках могут быть свои сигналы. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: m_ax от Октябрь 20, 2015, 00:08 Цитировать Да, в наследниках могут быть свои сигналы. Ну тогда я бы особо не парился и сделал бы как Old предложил..Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 20, 2015, 00:55 Ну тогда я бы особо не парился и сделал бы как Old предложил.. Хорошо, я понял :). В любом случае, спасибо за предложенный вариант :). Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 20, 2015, 09:29 Замечательно :). Теперь спрячьте определение сигнала в разделе protected и обеспечьте возможность подключаться/отключаться к ним любому желающему. Есть правило "один топик - одна тема". На Ваш вопрос "буст сигнал+защита" ответ дан исчерпывающий. Теперь Вы хотите обсуждать др вещи (удобство и.т.п.) - почему бы и нет, но надо ясно сказать что это уже другое. А не ссылаться на то на что уже дан ответ. Насколько я понял, теперь Вы хотите так: - есть базовый класс к которому можно (динамически, в рантайм) добавить любой бустовский сигнал, удалить, сделать connect/disconnect и эмиттить этот сигнал (учитывая protected/private). Верно? Заметим что отказавшись от Qt сигналов Вы по-прежнему следуете Qt идеологии. Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 20, 2015, 10:44 Есть правило "один топик - одна тема". На Ваш вопрос "буст сигнал+защита" ответ дан исчерпывающий. Теперь Вы хотите обсуждать др вещи (удобство и.т.п.) - почему бы и нет, но надо ясно сказать что это уже другое. А не ссылаться на то на что уже дан ответ. Какой ответ в этой теме Вы считаете "исчерпывающим" для задачи, поставленной в первом сообщении? Его можно назвать единственно верным и оптимальным, исключающим появления лучших вариантов?Насколько я понял, теперь Вы хотите так: Неверно :). Я хочу не более того, что задано в первом сообщении. Там есть конкретный пример, аналог которого меня интересует. В нём никакие сигналы динамически не добавляются. И мне даже интересно, после каких моих слов Вы решили, что я захотел такое динамическое поведение в рантайм? :)- есть базовый класс к которому можно (динамически, в рантайм) добавить любой бустовский сигнал, удалить, сделать connect/disconnect и эмиттить этот сигнал (учитывая protected/private). Верно? Заметим что отказавшись от Qt сигналов Вы по-прежнему следуете Qt идеологии. Об этом можно поподробнее :). Какой Qt идеологии я следую? Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: Igors от Октябрь 20, 2015, 13:11 Там есть конкретный пример, аналог которого меня интересует. В нём никакие сигналы динамически не добавляются. И мне даже интересно, после каких моих слов Вы решили, что я захотел такое динамическое поведение в рантайм? :) А почему? Если сигнал - переменная, то кто нам может помешать доливать их в рантайме? Правда не знаю как это сделать, типы-то разные. Но по-моему это интересно и небезвыгодно - хотя бы не отягощаем никого "классовостью", множ наследование - пожалуйста. Об этом можно поподробнее :). Какой Qt идеологии я следую? Да всей, поскольку ничего нового не видно. Также лепите сигналы-члены класса, коннект - по объектам и.т.п. Только вместо готового сервиса в Qt - пучина мутных темплейтов. Ну и за что боролись?Название: Re: Protected вызов сигналов в Boost.Signals2 Отправлено: ViTech от Октябрь 20, 2015, 13:33 А почему? Если сигнал - переменная, то кто нам может помешать доливать их в рантайме? Правда не знаю как это сделать, типы-то разные. Но по-моему это интересно и небезвыгодно - хотя бы не отягощаем никого "классовостью", множ наследование - пожалуйста. Динамическое добавление и удаление сигналов может быть интересно для каких-то случаев. Но это и правда, тема отдельного разговора. В этой же меня интересуют варианты compile-time.Да всей, поскольку ничего нового не видно. Также лепите сигналы-члены класса, коннект - по объектам и.т.п. Только вместо готового сервиса в Qt - пучина мутных темплейтов. Ну и за что боролись? Так я ничего нового и не хотел :). Требовалось то же самое поведение сигналов, которое было в Qt 4, только с реализацией на boost::signals2. Зачем это потребовалось - дело другое. Можете выбрать любую версию, от академического интереса до той, где не всё приложение использует инфраструктуру Qt, а только в GUI, основное же ядро и библиотеки используют boost и std. |