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

Если они связаны

Давайте на мгновение предположим, что B на самом деле является основанием D. Тогда для вызова check обе версии жизнеспособны, поскольку Host можно преобразовать в D* и B*. Это определяемая пользователем последовательность преобразования, описанная 13.3.3.1.2 от Host<B, D> до D* и B* соответственно. Для поиска функций преобразования, которые могут преобразовать класс, синтезируются следующие функции-кандидаты для первой функции check в соответствии с 13.3.1.5/1

D* (Host<B, D>&)

Первая функция преобразования не подходит, потому что B* нельзя преобразовать в D*.

Для второй функции существуют следующие кандидаты:

B* (Host<B, D> const&)
D* (Host<B, D>&)

Это два кандидата в функции преобразования, которые принимают хост-объект. Первый берет его по константной ссылке, а второй нет. Таким образом, второй лучше соответствует неконстантному объекту *this (подразумеваемый аргумент объекта) по 13.3.3.2/3b1sb4 и используется для преобразования в B* для второй функции check.

Если бы вы удалили константу, у нас были бы следующие кандидаты

B* (Host<B, D>&)
D* (Host<B, D>&)

Это означало бы, что мы больше не можем выбирать по константе. В обычном сценарии разрешения перегрузки вызов теперь будет неоднозначным, поскольку обычно возвращаемый тип не участвует в разрешении перегрузки. Однако для функций преобразования есть лазейка. Если две функции преобразования одинаково хороши, то тип их возвращаемого значения решает, какая из них лучше согласно 13.3.3/1. Таким образом, если бы вы убрали константу, то была бы взята первая, потому что B* лучше преобразуется в B*, чем D* в B*.

Какая определенная пользователем последовательность преобразования лучше? Один для второй или первой функции проверки? Правило состоит в том, что определяемые пользователем последовательности преобразования можно сравнивать только в том случае, если они используют одну и ту же функцию преобразования или конструктор в соответствии с 13.3.3.2/3b2. Здесь именно так: оба используют вторую функцию преобразования. Обратите внимание, что таким образом const важен, потому что он заставляет компилятор использовать вторую функцию преобразования.

Так как мы можем их сравнить - какой из них лучше? Правило состоит в том, что лучшее преобразование из типа, возвращаемого функцией преобразования, в тип назначения выигрывает (опять же на 13.3.3.2/3b2). В этом случае D* лучше конвертируется в D*, чем в B*. Таким образом выбирается первая функция и мы признаем наследство!

Обратите внимание: поскольку нам никогда не нужно было на самом деле преобразовывать в базовый класс, мы можем, таким образом, распознать частное наследование, потому что возможность преобразования из D* в B* не зависит от форма наследования по 4.10/3

Если они не родственники

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

D* (Host<B, D>&) 

А для второго у нас теперь другой набор

B* (Host<B, D> const&)

Поскольку мы не можем преобразовать D* в B*, если у нас нет отношения наследования, у нас теперь нет общей функции преобразования среди двух определяемых пользователем последовательностей преобразования! Таким образом, мы были бы неоднозначны, если бы не тот факт, что первая функция является шаблоном. Шаблоны — это второй вариант, когда есть функция, не являющаяся шаблоном, которая одинаково хороша в соответствии с 13.3.3/1. Таким образом, мы выбираем нешаблонную функцию (вторую) и признаем, что между B и D нет наследования!

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

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

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

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

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

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

Бит 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 является частной базой, не мешает проверке, это только предотвратит конвертацию, но мы никогда не просим фактическую конвертацию ;)

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

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

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

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

Следуя вашему второму вопросу, обратите внимание, что если бы не const, Host был бы неправильно сформирован, если бы он был создан с помощью B == D. Но is_base_of разработан таким образом, что каждый класс является базой для себя, поэтому один из операторов преобразования должен быть постоянным