Как запретить производному классу сделать частную / защищенную виртуальную функцию общедоступной?

Как сказал Бьярн, контроль доступа в C ++ предназначен для защиты от Мерфи, а не от Макиавелли. То же самое и в целом - его функции предназначены для защиты от несчастных случаев, а не для того, чтобы люди намеренно делали что-то не так.

В некоторой степени использование C ++ означает хотя бы некоторую степень доверия к другим людям, которые будут иметь доступ к вашему исходному коду. Если они захотят достаточно сильно, они могут облажаться всеми способами, и вы ничего не сможете сделать, чтобы их остановить. Если вы хотите наложить реальные ограничения на использование вашего кода, C ++ - неподходящий язык для ваших целей.

Изменить: это вообще не «аргумент» - это просто указание на основу, на которой были приняты решения. Поскольку у меня есть копия D&E после ответа на предыдущий вопрос, я напечатаю немного больше, если она здесь ¹:

Гораздо важнее разрешить полезную функцию, чем предотвратить любое неправильное использование: Вы можете писать плохие программы на любом языке. Важно свести к минимуму вероятность случайного неправильного использования функций, и было потрачено много усилий на то, чтобы гарантировать, что поведение конструкций C ++ по умолчанию является разумным или приводит к ошибкам во время компиляции. Например, по умолчанию проверяются все типы аргументов функции - даже через отдельные границы компиляции - и по умолчанию все члены класса являются закрытыми. Однако язык системного программирования не может помешать решительному программисту сломать систему, поэтому усилия по проектированию лучше направить на создание возможностей для написания хороших программ, чем на предотвращение неизбежных плохих. В долгосрочной перспективе программисты, кажется, учатся. Это вариант старого слогана C «Доверься программисту». Существуют различные правила проверки типов и контроля доступа, позволяющие провайдеру класса четко указывать, что ожидается от пользователей, для защиты от несчастных случаев. Эти правила не предназначены для защиты от преднамеренного нарушения (§2.10).

В §2.10 он, среди прочего, говорит:

Задача системы защиты - убедиться, что любое такое нарушение системы типов является явным, и минимизировать необходимость в таких нарушениях.

Эти цели здесь, похоже, были достигнуты - публикация защищенного члена базового класса определенно требует явных действий в производном классе, и за более чем 20 лет написания C ++ я не могу припомнить, чтобы когда-либо нуждался (или даже хотел) в этом.

¹ §4.3, стр. 115, 116.

Вы не можете. «виртуальность» функции и типа доступа - это два разных, не связанных между собой понятия.

Повышение уровня частного / защищенного виртуального метода до общедоступного в производном классе не раскрывает метод базового класса. Его по-прежнему нельзя вызвать через указатель базового класса. Он не становится частью интерфейса базового класса.

Контроль доступа в C ++, возможно, не делает того, что вы хотите. Он не предназначен для применения ограничений в стиле DRM, чтобы помешать вам делиться своим доступом. Если у A есть доступ к B, то A может вызвать B и использовать результат для любых целей, в том числе вернуть его другому вызывающему абоненту, у которого нет доступа к B.

Проблема, которая обсуждается в статье, на которую вы ссылаетесь, не связана с намеренным или злонамеренным обменом B. Шаблоны шаблонных методов, включая частные виртуальные функции. Дочерние классы написали общедоступные переопределения виртуальной функции, поэтому вы больше не можете разделять две проблемы (доступ и виртуальность) без изменения всех дочерних классов. Насколько я понимаю, статья действительно предлагает решение проблемы, которую она представляет, и это решение состоит в том, чтобы «вообще никогда не делать виртуальные функции общедоступными».

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

Причина, по которой это не решает вашу проблему, заключается в том, что они не учли вашу проблему.

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

С чего бы это? Конструктор каждого класса должен решить, какой внешний интерфейс он имеет.

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

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

protected:
class ProtectedToken { virtual ~ProtectedToken() { } };
virtual void my_tough_cookie(int arg,
  ProtectedToken const &tok = ProtectedToken() ) {
    assert ( typeid( tok ) == typeid( ProtectedToken ) );
    …
}

Конечно, это нехорошо ни с кем, в том числе с самим собой.

Изменить: Ба, это не работает. Даже если бы это было так, вы могли бы сделать public: using Base::ProtectedToken и таким образом обойти защиту. Еще 15 минут моей жизни потрачены впустую ...