Как 'is_base_of' работает?

Давайте разберемся, как это работает, рассмотрев шаги.

Начнем с части sizeof(check(Host(), int()))). Компилятор может быстро увидеть, что этот check(...) является выражением вызова функции, поэтому ему нужно выполнить разрешение перегрузки для check. Имеются две кандидатные перегрузки, template yes check(D*, T); и no check(B*, int);. Если выбрана первая, то вы получите sizeof(yes), иначе sizeof(no)

Далее рассмотрим разрешение перегрузки. Первая перегрузка - это инстанцирование шаблона check (D*, T=int), а второй кандидат - check(B*, int). Фактические предоставленные аргументы - Host и int(). Второй параметр явно не различает их; он просто служит для того, чтобы сделать первую перегрузку шаблонной. Позже мы увидим, почему шаблонная часть имеет значение.

Теперь посмотрим на необходимые последовательности преобразования. Для первой перегрузки у нас есть Host::operator D* - одно пользовательское преобразование. Для второй перегрузки все сложнее. Нам нужен B*, но возможны две последовательности преобразования. Одна - через Host::operator B*() const. Если (и только если) B и D связаны наследованием, будет существовать последовательность преобразования Host::operator D*() + D*->B*. Теперь предположим, что D действительно наследуется от B. Две последовательности преобразования: Host -> Host const -> operator B* const -> B* и Host -> operator D* -> D* -> B*.

Таким образом, для связанных B и D, отсутствие check((), int()) будет неоднозначным. В результате выбирается шаблонизированный yes check(D*, int). Однако, если D не наследуется от B, то no check((), int()) не будет двусмысленным. На данный момент разрешение перегрузки не может происходить на основе кратчайшей последовательности преобразования. Однако при равных последовательностях преобразования разрешение перегрузки предпочитает нешаблонные функции, т.е. нет check(B*, int).

Теперь вы видите, почему не имеет значения, что наследование является частным: это отношение служит только для того, чтобы исключить no check(Host(), int()) из разрешения перегрузки до того, как произойдет проверка доступа. И вы также видите, почему оператор B* const должен быть const: иначе нет необходимости в шаге Host -> Host const, нет двусмысленности, и no check(B*, int) всегда будет выбран.

Возможно, это как-то связано с частичным упорядочиванием при разрешении перегрузки. D* является более специализированным, чем B*, в случае, если D происходит от B.

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

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

Что касается того, что наследование является привилегированным: в коде никогда не спрашивается о преобразовании из D* в B*, что потребовало бы публичного наследования.

Бит private полностью игнорируется is_base_of, потому что разрешение перегрузки происходит до проверки доступности.

Вы можете проверить это просто:

class Foo
{
public:
  void bar(int);
private:
  void bar(double);
};

int main(int argc, char* argv[])
{
  Foo foo;
  double d = 0.3;
  foo.bar(d);       // Compiler error, cannot access private member function
}

То же самое применимо и здесь, тот факт, что B является частной базой, не препятствует проверке, он только препятствует преобразованию, но мы никогда не спрашиваем о фактическом преобразовании ;)