typedef char (&yes)[1];
typedef char (&no)[2];

template <typename B, typename D>
struct Host
{
  operator B*() const;
  operator D*();
};

template <typename B, typename D>
struct is_base_of
{
  template <typename T> 
  static yes check(D*, T);
  static no check(B*, int);

  static const bool value = sizeof(check(Host<B,D>(), int())) == sizeof(yes);
};

//И тестовый пример:
class B {};
class D : private B {};

//Успешная компиляция следующей строчки означает, что выражение в квадратных скобках истинно
int test[is_base_of<B,D>::value && !is_base_of<D,B>::value];

typedef char (&yes)[1];
typedef char (&no)[2];

template <typename B, typename D>
struct Host
{
    operator B*() const        { return new B; }
    operator D*()            { return new D; }
};


class C {};
class E : private C {};

template <typename T>
void                    check(E*, T)            { int i = 0; }
void                    check(C*, int)            { int i = 0; }

check(Host<C,E>(), int());    // Host<C,E>::operator E*(Host<C,E>::operator D*) returned E*
check(Host<E,C>(), int());    // Host<E,C>::operator B*(Host<E,C>::operator D*) returned C*
const Host<C,E>            ConstHostCE;
check(ConstHostCE, int());    // Host<C,E>::operator B*(Host<C,E>::operator B*) returned C*

// Некоторые куски из параграф 13 нарисовал в БНФ (в скобках - сокращения):

implicit conversion sequence (ICS) :=  
   standard conversion sequence (SCS)
 | user-defined conversion sequence (UDCS) 
 | ellipsis conversion sequence

SCS := 
   Identity 
 | Category_list 

Category_list :=
 Category Category_opt Category_opt // + правила из 13.3.3.1.1/2
     
//  User-defined conversion sequence Представляет собой(13.3.3.1.2/1) 
//  последовательность из следующих обязательных частей:
//  1) initial SCS 
//  2) user-defined conversion (UDC) // не UDCS!
//  3) second SCS

UDCS := 
 SCS UDC SCS

UDC := 
   Conversion_function
 | ...

check(Host<B,D>(), int())

UDCS1:
1) H -> H   [SCS]{Identity}
2) H -> D*  [UDC] 
3) D* -> D* [SCS]{Identity}

UDCS2.1:
1) H  -> H  [SCS]{Identity}
1) H  -> D* [UDC]
2) D* -> B* [SCS]{Pointer conversion}

UDCS2.2
1) H -> H const  [SCS]{Qualification Adjustment}
2) H const -> B* [UDC]
3) B*  -> B*     [SCS]{Identity}

When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argument expression.

User-defined conversion sequence U1 is a better conversion sequence than another user-defined conversion sequence U2 if they contain the same user-defined conversion function or constructor and if the second standard conversion sequence of U1 is better than the second standard conversion sequence of U2.

UDCS1:
1) H -> H   [SCS]{Identity}
2) H -> D*  [UDC] 
3) D* -> D* [SCS]{Identity}

UDCS2
1) H -> H const  [SCS]{Qualification Adjustment}
2) H const -> B* [UDC]
3) B*  -> B*     [SCS]{Identity}

UDCS1:
ЮЖ>>1) H -> H   [SCS]{Identity}
ЮЖ>>2) H -> D*  [UDC] 
ЮЖ>>3) D* -> D* [SCS]{Identity}

UDCS2.1:
ЮЖ>>1) H  -> H  [SCS]{Identity}
ЮЖ>>1) H  -> D* [UDC]
ЮЖ>>2) D* -> B* [SCS]{Pointer conversion}

ЮЖ>>UDCS2.2
ЮЖ>>1) H -> H const  [SCS]{Qualification Adjustment}
ЮЖ>>2) H const -> B* [UDC]
ЮЖ>>3) B*  -> B*     [SCS]{Identity}

When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argument expression (13.3.3.1/6).

When a parameter of reference type binds directly (8.5.3) to an argument expression, the implicit conversion sequence is the identity conversion, unless the argument expression has a type that is a derived class of the parameter type, in which case the implicit conversion sequence is a derived-to-base Conversion [Example ...] If the parameter binds directly to the result of applying a conversion function to the argument expression, the implicit conversion sequence is a user-defined conversion sequence (13.3.3.1.2), with the second standard conversion sequence either an identity conversion or, if the conversion function returns an entity of a type that is a derived class of the parameter type, a derived-to-base Conversion.

The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. For the purposes of overload resolution, both static and non-static member functions have an implicit object parameter, but constructors do not.

For non-static member functions, the type of the implicit object parameter is “reference to cv X” where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [Example: for a const member function of class X, the extra parameter is assumed to have type “reference to const X”. ] For conversion functions, the function is considered to be a member of the class of the implicit object argument for the purpose of defining the type of the implicit object parameter.

— Standard conversion sequence S1 is a better conversion sequence than standard conversion sequence
S2 if
[...]
— S1 and S2 are reference bindings (8.5.3), and the types to which the references refer are the same type except for top-level cv-qualifiers, and the type to which the reference initialized by S2 refers is more cv-qualified than the type to which the reference initialized by S1 refers.

a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then — for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2)

The implicit object parameter, however, retains its identity since conversions on the corresponding argument shall obey these additional rules:

— no temporary object can be introduced to hold the argument for the implicit object parameter;

— no user-defined conversions can be applied to achieve a type match with it; and

— even if the implicit object parameter is not const-qualified, an rvalue temporary can be bound to the parameter as long as in all other respects the temporary can be converted to the type of the implicit object parameter.

UDCS1:
ЮЖ>>1) H -> H   [SCS]{Identity}
ЮЖ>>2) H -> D*  [UDC] 
ЮЖ>>3) D* -> D* [SCS]{Identity}

13.3.1.5/1 Initialization by conversion function
Under the conditions specified in 8.5, as part of an initialization of an object of nonclass type, a conversion
function can be invoked to convert an initializer expression of class type to the type of the object being initialized.
Overload resolution is used to select the conversion function to be invoked. Assuming that “cv1
T” is the type of the object being initialized, and “cv S” is the type of the initializer expression, with S a
class type, the candidate functions are selected as follows:

13.3.1.5/2
The argument list has one argument, which is the initializer expression. [Note: this argument will be compared
against the implicit object parameter of the conversion functions. ]

Given these definitions, a viable function F1 is defined to be a better function than another viable function
F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then
— for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,
...
— the context is an initialization by user-defined conversion (see 8.5, 13.3.1.5, and 13.3.1.6) and the standard
conversion sequence from the return type of F1 to the destination type (i.e., the type of the entity
being initialized) is a better conversion sequence than the standard conversion sequence from the return
type of F2 to the destination type. [Example:
struct A {
A();
operator int();
operator double();
} a;
int i = a; // a.operator int() followed by no conversion
// is better than a.operator double() followed by
// a conversion to int
float x = a; // ambiguous: both possibilities require conversions,
// and neither is better than the other
—end example]