В чем потенциальная опасность превращения частной функции в публичную?

В чем разница между объявлением виртуальной функции частным, защищенным и общедоступным в базовом объекте?

Разница в том, что виртуальная функция private может быть вызвана только из базового класса. Это может быть полезно, если функция не является частью интерфейса внешнего класса и используется только базовым классом. Таким образом, пользователи вызывают член (некоторого другого) базового класса, и этот член вызывает виртуальную функцию. Например:

class Base {
    virtual void stage1()=0;  // derived classes override this
    virtual void stage2()=0;
  public:
    void run() { stage1(); stage2(); } // users call this
};

Более того, существует точка зрения, что вы не должны делать свои виртуальные функции public вообще, потому что тот факт, что они виртуальные, является внутренним компонентом класса и его подклассов, и пользователи не должны знать об этом. Редко бывает, что одна и та же функция должна быть переопределена и вызвана из внешнего кода. Это позволяет базовому классу контролировать, какие (виртуальные) функции могут быть вызваны из какого (не виртуального) общедоступного метода, что упрощает обслуживание.

Дополнительные сведения см. В этой статье Херба Саттера:

... каждая [общедоступная] виртуальная функция выполняет две задачи: определяет интерфейс, потому что он общедоступен ...; и он определяет детали реализации, а именно внутренне настраиваемое поведение ... То, что общедоступная виртуальная функция по своей сути выполняет две существенно разные задачи, является признаком того, что она плохо разделяет задачи и что мы должны рассмотреть другой подход. Что, если мы хотим отделить спецификацию интерфейса от спецификации настраиваемого поведения реализации?

...

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

Однако я не могу сказать, действительно ли это широко используется ...

Есть ли в этом потенциальная опасность?

Я так не думаю, потому что вы все еще очень ограничены:

class Base
{
private:
    virtual void foo(){}
};

class Derived1 : public Base
{
public:
    virtual void foo(){ Base::foo(); }
};

class Derived2 : public Base
{
public:
    virtual void foo(){}
};

int main()
{
    Derived1 d1;
    d1.foo(); //error
    Base * d2 = new Derived2();
    d2->foo(); //error
}

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

При изменении видимости доступа путем переопределения в производном классе видимость базового класса не изменяется:

Итак, с:

class Base {
public:
    virtual ~Base() = default;
protected:
    virtual void foo() = 0;
};

class Derived : public Base {
public:
    void foo() override {};
};

потом

Derived d;
Base& b = d;

d.foo(); // valid
b.foo(); // invalid

Если нет, в чем разница между объявлением виртуальной функции private, protected и public в базовом объекте?

Это зависит от того, как вы получаете доступ к функции. Тип используемого объекта / указателя определяет, можете ли вы получить доступ к функции.

class Base
{
   public:

      virtual void foo() {}
};

class Derived : public Base
{
   private:

      virtual void foo() {}
};

int main()
{
   Derived* dptr = new Derived;
   Base* bptr = dptr;

   dptr->foo();  // Can't use it. Derived::foo is private
   bptr->foo();  // Can use it. Base::foo is public.
}

Сообщение компилятора с использованием g ++ 4.9.3.

socc.cc: In function ‘int main()’:
socc.cc:12:20: error: ‘virtual void Derived::foo()’ is private
       virtual void foo() {}
                    ^
socc.cc:20:14: error: within this context
    dptr->foo();  // Can't use it. Derived::foo is private

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