samedi 13 novembre 2021

How to determine two implicit conversion sequences preferred than each other for overload resolution?

I want to question about overload resolution accompanying an implicit type conversion.

It seems that an implicit conversion sequence has at most three steps to convert an type T1(argument type) to T2(parameter type):

  1. zero or one standard conversion sequence;
  2. zero or one user-defined conversion; ( I want to ignore this step because it isn't related to this question.)
  3. zero or one standard conversion sequence.

An implicit conversion sequence can be categorized as one of:

  • a standard conversion sequence (I am interested this fundamental type conversions case only.)
  • a user-defined conversion sequence
  • an ellipsis conversion sequence

And, each type of standard conversion sequence is assigned one of three ranks:

  1. Exact match
  2. Promotion
  3. Conversion

I think there will be a case where two implicit conversion sequences have its constituent standard conversion sequence steps which have different ranks each other. So, IMHO it is hard for me to determine which implicit conversion sequence is preferred than the other.

For example(Unfortunately, i couldn't come up with a concrete example.),

An implicit conversion sequence (A) consists of

  1. standard conversion sequence (A-1) which is rank exact match.
  2. no user-defined conversion sequence
  3. standard conversion sequence (A-2) which is rank conversion.

The other implicit conversion sequence (B) consists of

  1. standard conversion sequence (B-1) which is rank conversion.
  2. no user-defined conversion sequence
  3. standard conversion sequence (B-2) which is rank exact match.

In this case, A-1 is preferred than B-1 but B-2 is preferred than A-2. So, each of A and B have own preferences. -> ambiguous call?

OR... A-1 and B-1 should be compared first than A-2 and B-2. So, should we stop comparing each other here for greedy comparison? -> The A is chosen?

Aucun commentaire:

Enregistrer un commentaire