Почему виртуальная функция была бы частной?

ISO C ++ 2003 явно разрешает это:

§10.3 ничего не говорит о спецификаторе доступа и содержит даже сноску во втором предложении, в контексте переопределения виртуальных функций:

[...] Контроль доступа (пункт 11) не учитывается при определении

Код полностью допустим.

Это чистая виртуальная функция, которая оказывается частной. Это делает так, что производный класс должен реализовывать метод. В этом случае Bar.

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

Относительно плохой пример :)

class RecordFile
{
    public:
       RecordFile(const std::string &filename);

       void process(const Record &rec)
       {
           // Call the derived class function to filter out
           // records the derived instance of this class does
           // not care about
           if (filterRecord(rec))    
           {
               writeRecordToFile(rec);           
           }
       };

    private:
       // Returns true if the record is of importance
       // and should be kept
       virtual bool filterRecord(const Record &rec) = 0;

       void writeRecordToFile(const Record &rec);
};

Я собираюсь процитировать краткое объяснение из великого C ++ FAQ Lite , которое хорошо подводит итог:

[23.4] Когда следует использовать частный виртуальные?

Почти никогда.

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

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

Если нет веской причины напротив, избегайте частных виртуальных машин.

Тем временем были обновлены C ++ FAQ Lite:

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

Обычный «академический» ответ: спецификаторы доступа и виртуальность ортогональны - одно не влияет на другое.

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

Это чистая виртуальная функция. Любая окончательная реализация, производная от «Foo», ДОЛЖНА реализовывать функцию «Bar».

Это делает функцию чистой виртуальной, а не виртуальной.

По умолчанию реализация не предоставляется, и предполагается, что реализация функции должна быть указана наследующим классом. Однако это можно переопределить.

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

Это абстрактные базовые классы, иногда называемые интерфейсными классами, а разработчик ABC - говоря вам: «Теперь я знаю, как эта функциональность будет реализована для всех специализаций этого базового класса. Но вы должны иметь все это, чтобы ваша специализация работала, и вы знаете, как должен вести себя ваш объект».

Изменить: Ой, только что заметил тот факт, что чистая виртуальная функция члена является частной. (Спасибо, Майкл) Это немного меняет ситуацию.

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

Итак, некоторая общедоступная функция в Foo вызывает функцию Bar внутри Foo, и он полагается на тот факт, что вы предоставите специализированную реализацию функции Bar для вашего конкретного случая.

Скотт Мейерс называет это «реализованным в терминах».

BTW Просто посмеиваюсь над количеством ответов, которые были быстро удалены людьми, которые также не увидели "мелкий шрифт" в вопросе! (-:

HTH

ура,

Единственная цель, которой он, кажется, служит - предоставить общий интерфейс.

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

Тем не менее, такого рода вещи обычно предназначены для использования в качестве интерфейса, но я не сделай это так.