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

[ViTech]

Код

C++ (Qt)
class BaseQtShape : public QObject
{
...
private:
    Q_INVOKABLE void test(bool value)
    { std::cout << "Test: " << value << std::endl; }
};
 
int main()
{
    QMetaObject::invokeMethod(&shape, "test", Q_ARG(bool, true));
}
 

Таким макаром можно официально и приватные методы вызывать . И да, я в ужасе от таких возможностей. О чём это говорит? О том, что они специально так сделали, чтобы защищённые методы вызывать, или просто не стали в мета-информацию закладывать уровни доступа?

Почему тогда они стесняются пойти дальше и в той же версии Qt 4.x пишут:

Код:

Only the class that defines a signal and its subclasses can emit the signal.

[Old]

О том, что они специально так сделали, чтобы защищённые методы вызывать, или просто не стали в мета-информацию закладывать уровни доступа?

Если закладывать уровни доступа, то их нужно проверять в runtime. Каждый вызов слота должен проверяться. А чего добиваемся? Пытаемся дублировать уровни доступа языка, которые проверяются в compiletime?

[ViTech]

Если закладывать уровни доступа, то их нужно проверять в runtime. Каждый вызов слота должен проверяться. А чего добиваемся? Пытаемся дублировать уровни доступа языка, которые проверяются в compiletime?

Так я о том и спрашиваю . Я не знаю, чем руководствовались разработчики, позволяя через invokeMethod вызывать защищённые методы.

Стоит к invokeMethod относиться как к "официальной возможности", или всё же эта штука больше нужна для внутренних потребностей Qt? И раз она такая полезная оказалась, то дали возможность её всем пользоваться, взамен ожидая осторожности, поскольку она нарушает инкапсуляцию.

[Bepec]

Qt развивается в сторону удобства разработчиков. Да, попираются стандарты, да, возможны отходы в сторону неоптимальных и "неправильных" в ООП вещах.
Но это удобно

to m_ax: пролетел темку, не нашёл места где идёт переход с "хочу сделать так", на "должно соответствовать ООП"

[m_ax]

to m_ax: пролетел темку, не нашёл места где идёт переход с "хочу сделать так", на "должно соответствовать ООП"

Ну как же, первый пост:

Т.е. тот же самый набор сигналов и слотов в полном объеме и с наследованием. Сами сигналы публичные, подключиться и отключиться от них может кто угодно. Только чтобы вызов сигнала (emit) был protected и "снаружи" никто не мог вызвать сигнал.

[Igors]

Допустим есть пара методов:

Код

C++ (Qt)
public:
    void move(int x, int y);
signals:
    void moved(int x, int y);
 

Велика ли вероятность ошибочного вызова shape.moved(x, y)? Со всеми этими "code completion" в редакторе, можно же просто промазать. Когда в запарке что-то быстро пишется, текст программы уже сливается, глаз замылился. Или все разработчики всегда собраны, всегда всё за собой проверяют, читают документацию?

К сожалению да, такая вероятность велика. Я часто влетаю на аналогичном normalize/normalized. Но это никак не связано с слот/сигнал.

Так что там с бустом, разобрались? Да, я видел пример m_ax, но как-то.. сходу непонятно, а вникать нет необходимости. Почти наверняка бустовская реализация "профессиональнее", но в Qt на нем навешаны вкуснейшие плюшки. Напр легким движением руки (QueuedConnection) сигнал превращается в элегантное событие. Хотя бы ради этого можно и потерпеть гнусное "мокирование", а о такой мелочи как public неудобно и говорить

[ViTech]

Так что там с бустом, разобрались? Да, я видел пример m_ax, но как-то.. сходу непонятно, а вникать нет необходимости. Почти наверняка бустовская реализация "профессиональнее", но в Qt на нем навешаны вкуснейшие плюшки. Напр легким движением руки (QueuedConnection) сигнал превращается в элегантное событие. Хотя бы ради этого можно и потерпеть гнусное "мокирование", а о такой мелочи как public неудобно и говорить

Конечно, большие минусы сигнал-слотов Qt явно не в том, что в 5-ой версии emit вдруг стал публичным . Всё слишком завязано на инфраструктуру Qt в общем (что не удивительно), и на QObject в частности. Не всем и не всегда охота наследоваться от QObject или таскать его с собой, чтобы рассылать сигналы. Поэтому стало интересно, как обстоят дела в других системах сигнал-слот.

Ради одного сигнала из буста я бы не стал такой огород городить. Всё тривиально и в документации расписано. А вот как это использовать в более-менее большом проекте, который ещё хочет следовать "канонам ООП" . Поэтому и говорил о "полном наборе сигналов и наследовании".

Вариант Old работает "здесь и сейчас", но в длительной перспективе использования мне он не очень нравится, и я писал почему. Вариант m_ax мне нравится больше, но дружба дружбой, а сигналы врозь . Требование по наследованию не выполняется. Потомки Demo не смогут вызвать родительский my_signal.

В конечном итоге хотелось бы такой же лёгкости и краткости в описании сигналов, как в Qt . Вот и стало интересно, насколько это реально с использованием сигналов буста. Пусть даже и с шаблонизацией 80-го уровня.

[Racheengel]

Как по мне,

А вот как это использовать в более-менее большом проекте, который ещё хочет следовать "канонам ООП"

и

Пусть даже и с шаблонизацией 80-го уровня.

это вещи взаимоисключающие.

Да, и каким образом модель сигналов-слотов Qt противоречит "канонам ООП"? Это всего лишь способ обмена сообщениями между объектами в системе.

В конечном итоге хотелось бы такой же лёгкости и краткости в описании сигналов, как в Qt

Так ответ в этой вашей фразе Просто Используйте Сигналы Qt

[Igors]

Не всем и не всегда охота наследоваться от QObject или таскать его с собой, чтобы рассылать сигналы.

Да, это аргумент. Как говорил Штирлиц

Вот с этого и надо было начинать

[Racheengel]

А, так речь о том, чтобы симулировать кутишные сигналы не-кутишными средствами?
Я-то был уверен, что автор хочет зарубить вызовы кутишных сигналов, если они не public...

[Bepec]

Он хочет сигналы с функциональностью Qt, но имеющие защиту от вызова из "посторонних" классов и поддерживающие наследование. Т.е. с защитой доступа.

Пока решения ему не предложили, которое бы удовлетворяло

[ViTech]

Ещё немного, и мне припишут, что я хочу на Марс на боинге долететь .

А, так речь о том, чтобы симулировать кутишные сигналы не-кутишными средствами?
Я-то был уверен, что автор хочет зарубить вызовы кутишных сигналов, если они не public...

Автор хочет лишь того, что обозначено в первом сообщении. Или хотя бы название темы внимательно прочитайте.

[Racheengel]

Он хочет сигналы с функциональностью Qt, но имеющие защиту от вызова из "посторонних" классов и поддерживающие наследование. Т.е. с защитой доступа.

Пока решения ему не предложили, которое бы удовлетворяло

Написать кутишникам и попросить сделать спецверсию сигналслотов, как вариант

Хотя это желание из серии "хочу мерседес с двигателем от Т90"...

[Racheengel]

Автор хочет лишь того, что обозначено в первом сообщении.

Просто от вас народ так и не добился, какая ПРАКТИЧЕСКАЯ НЕОБХОДИМОСТЬ такой штуки...
Если просто эксперимента, ну так вариантов немного, и все кривые.
Для реальных проектов это не нужно...

[ViTech]

Просто от вас народ так и не добился, какая ПРАКТИЧЕСКАЯ НЕОБХОДИМОСТЬ такой штуки...
Если просто эксперимента, ну так вариантов немного, и все кривые.

Почему-то Old и m_ax не понадобилось ничего добиваться, чтобы предложить конкретный вариант . Вы хотя бы какой-нибудь вариант можете предложить, хоть кривой? Может там совсем немного надо подправить, чтобы выпрямить.

Для реальных проектов это не нужно...

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