Protected вызов сигналов в Boost.Signals2

[Igors]

вы бы стали использовать такой вариант в production в большом проекте? Какие плюсы и минусы видите?

В большом проекте давно решено какие слот/сигнал юзать, даже попытки пересмотра этого решения будут стоить очень дорого. Поэтому не надо парить про мифическую защиту, скажите просто "хочу попробовать на бусте" - в этом нет ничего плохого 

[Racheengel]

Нет, ибо чукча - не всегда писатель, но иногда и читатель

Господи, а что плохо читается в этом?

Код

C++ (Qt)
DEF_SIGNAL( update, void() )
 

Ненативно

Это мы с вами сейчас понимаем, о чем идет речь, а Раджапраштану из Бангалора может стать не по себе

[ViTech]

Просто чтобы понять... Вы хотите предотвратить взлом системы?

Это к вопросу инкапсуляции, и необходимости Приватных методов, обсуждение которых было таким бурным . А может и правда, чего нам скрывать? И дать возможность сигналить от нашего имени всем, кому не лень .

Вообще можно, но из-за двух методов connect/disconnect может и не стоит..

Но как вариант:
...

Этот вариант мне нравится значительно больше. Хотя я не фанат дружбы friend. Кстати, почему не стоит? И как тогда стоит?

В большом проекте давно решено какие слот/сигнал юзать, даже попытки пересмотра этого решения будут стоить очень дорого. Поэтому не надо парить про мифическую защиту, скажите просто "хочу попробовать на бусте" - в этом нет ничего плохого 

Я интереса "хочу попробовать на бусте" вроде как изначально и не скрывал . Нужна эта "мифическая защита" или нет, меня тоже интересует, и мнения по этому поводу. А так же есть ли такая система сигнал-слот, которая отвечает канонам ООП.

[Old]

Ненативно

Это мы с вами сейчас понимаем, о чем идет речь, а Раджапраштану из Бангалора может стать не по себе

Ну конечно, Q_OBJECT нативненько, а это не нативненько.
Все документируется и даже последний индус все поймет.

[Old]

А так же есть ли такая система сигнал-слот, которая отвечает канонам ООП.

До введения нового формата коннекта отвечала Qtшная.
Мне кажется, что на чистом С++ без moc такое сделать будет не легко, если вообще возможно.

[m_ax]

Кстати, почему не стоит? И как тогда стоит?

Ну не знаю) У меня нет универсального рецепта) Это уже вы сами решайте)

[ViTech]

До введения нового формата коннекта отвечала Qtшная.
Мне кажется, что на чистом С++ без moc такое сделать будет не легко, если вообще возможно.

Ну не знаю) У меня нет универсального рецепта) Это уже вы сами решайте)

Хорошо. Тогда акцент на то, нужно ли вообще вызов сигналов прятать? Или это желание из разряда: "Ишь чего захотел!"? Или, если с этим прятаньем так много возни и трудно реализовать, то и фиг с ней, инкапсуляцией? Это же сигналы, их в здравом разуме никто же не будет снаружи без причины вызывать.

[Old]

Это же сигналы, их в здравом разуме никто же не будет снаружи без причины вызывать.

this.

Защита в С++ сделана как защита от ошибок, а не как защита от злоумышленника. Если кому-то понадобиться, то он легко сможет вызывать и приватные методы.

[Bepec]

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

[ViTech]

Защита в С++ сделана как защита от ошибок, а не как защита от злоумышленника. Если кому-то понадобиться, то он легко сможет вызывать и приватные методы.

Со злоумышленниками понятно, от них не защитишься. А как быть с не очень опытными разработчиками, или теми, кто "сделаю щас быстренько, тут проще самому сигнал вызвать, чем ждать пока он появится"? Следить и по рукам бить? Или это слишком фантастический сценарий: неправильный вызов сигнала, и об этом не стоит беспокоиться?

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

Если не давать указатель, то и подключиться к нему никто не сможет . Толку от такого объекта с его сигналами .

Я так понимаю, что в конечном итоге всё сводится к порядочности и разумности разработчиков .

[Old]

Со злоумышленниками понятно, от них не защитишься. А как быть с не очень опытными разработчиками, или теми, кто "сделаю щас быстренько, тут проще самому сигнал вызвать, чем ждать пока он появится"? Следить и по рукам бить? Или это слишком фантастический сценарий: неправильный вызов сигнала, и об этом не стоит беспокоиться?

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

[Racheengel]

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

+1

Хорошо. Тогда акцент на то, нужно ли вообще вызов сигналов прятать? Или это желание из разряда: "Ишь чего захотел!"? Или, если с этим прятаньем так много возни и трудно реализовать, то и фиг с ней, инкапсуляцией? Это же сигналы, их в здравом разуме никто же не будет снаружи без причины вызывать.

Здравый смысл никто не отменял. Если человек будет пытаться сделать подобное - ССЗБ. Тем более, неопытный. Это ж еще ему до этого додуматься надо - вызвать эмит сигнала от имени левого класса

[Bepec]

Не отнимайте у юных и убогих возможность выстрелить себе в голову

[ViTech]

Не отнимайте у юных и убогих возможность выстрелить себе в голову

Ладно бы себе, они ж и другим отстрелить головы могут  .

[Bepec]

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

PS это же простое использование инкапсуляции - не хошь чтобы рылись в нутрях - дай только интерфейсный класс