как запретить наследование сигналов в классах

[shender]

Собственно вопрос такой есть класс "А" с сигналом "а", его наследует некий класс "В", как в нем скрыть присутствие сигнала из класс "А"

[Rcus]

Собственно языковыми средствами никак поскольку сигналы с точки зрения компилятора являются защищенными методами.
В Qt подобная проблема решена при помощи

Note: Components connected to this signal use it to adapt to changes in the model's dimensions. It can only be emitted by the QAbstractItemModel implementation, and cannot be explicitly emitted in subclass code.

И кто нарушит запрет тот ссзб.

[niXman]

Собственно языковыми средствами никак

ошибка. языковые средства тут не при чем. ибо в с++ сигналов не существует.

сигналы с точки зрения компилятора

снова ошибка. у компилятора нет точки зрения по этому поводу. ибо в с++ сигналов не существует 

[Rcus]

Ох, целых две ошибки в одном предложении.
Пойду убью себя ©

[SASA]

Собственно вопрос такой есть класс "А" с сигналом "а", его наследует некий класс "В", как в нем скрыть присутствие сигнала из класс "А"

а зачем?

[niXman]

Пойду убью себя ©

вариант.

[Igors]

Мне все эти все слоты/сигналы никогда не нравились (возможно предубеждение). Но объясните, где проблема? Ведь сигнал/слот требует connect. Хочешь - связывай, не хочешь - нет. Все равно все в руках связывающего. Зачем тогда искать ограничения (на непонятно что)?

[Zmeishe]

Мне все эти все слоты/сигналы никогда не нравились (возможно предубеждение).

Вполне возможно. Но мне очень понравились.

Но объясните, где проблема? Ведь сигнал/слот требует connect. Хочешь - связывай, не хочешь - нет. Все равно все в руках связывающего. Зачем тогда искать ограничения (на непонятно что)?

По моему автор темы хотел запретить в классе наследнике emit делать, а не связывание/развязывание.
Обратимся к Шлее:
Сигналы определяются в классе, как и обычные методы, только без реализации. С точки зрения программиста они являются только прототипами методов, содержащихся в заголовочном файле определения класса. Всю дальнейшую заботу о реализации кода для этих методов берёт на себя MOC.
Не имеет смысла определять сигналы как private, protected или public, так как они играют роль вызывающих методов.
Вывод:
В классе наследнике никак не скрыть присутствие сигнала из базового класса.

[SASA]

В классе наследнике никак не скрыть присутствие сигнала из базового класса.

Если речь идёт о запрещении эмита, то в классе наследнике надо переопредлить сигнал, сделав его обычным методом (возможно пустым). Тогда при вызове емитом не чего не произойдёт.
Знаю из горького опыта 

[Zmeishe]

А если так

Код:

class A: public QObject{
Q_OBJECT
 signals:
  void a();
}

class B: public A{
Q_OBJECT
  void a();
  void sendA()
  {
    emit A::a();
  }
}