Overload resolution

Afin de compiler un appel de fonction, le compilateur doit d'abord effectuer la recherche de nom , qui, pour les fonctions, peut impliquer la recherche dépendante des arguments , et pour les templates de fonction peut être suivie par la déduction d'arguments de template .

Si le nom fait référence à plus d'une entité, on dit qu'il est surchargé , et le compilateur doit déterminer quelle surcharge appeler. En termes simples, la surcharge dont les paramètres correspondent le plus étroitement aux arguments est celle qui est appelée.

En détail, la résolution de surcharge procède par les étapes suivantes :

1. Construction de l'ensemble des fonctions candidates .
2. Réduction de l'ensemble aux seules fonctions viables .
3. Analyse de l'ensemble pour déterminer la meilleure fonction viable unique (cela peut impliquer le classement des séquences de conversion implicite ).

void f(long);
void f(float);
f(0L); // appelle f(long)
f(0);  // erreur : surcharge ambiguë

En plus des appels de fonction, les noms de fonctions surchargées peuvent apparaître dans plusieurs autres contextes, où différentes règles s'appliquent : voir Adresse d'une fonction surchargée .

Si une fonction ne peut pas être sélectionnée par la résolution de surcharge, elle ne peut pas être utilisée (par exemple, il s'agit d'une entité templatée avec une contrainte échouée).

Fonctions candidates

Avant que la résolution de surcharge ne commence, les fonctions sélectionnées par la recherche de nom et la déduction d'argument de template sont combinées pour former l'ensemble des fonctions candidates . Les détails exacts dépendent du contexte dans lequel la résolution de surcharge aura lieu.

Appel à une fonction nommée

Si E dans une expression d'appel de fonction E ( args ) désigne un ensemble de fonctions surchargées et/ou de modèles de fonction (mais pas d'objets appelables), les règles suivantes sont appliquées :

• Si l'expression E a la forme PA - > B ou A. B (où A a un type classe cv T ), alors B est recherché en tant que fonction membre de T . Les déclarations de fonctions trouvées par cette recherche sont les fonctions candidates. La liste d'arguments pour la résolution de surcharge possède l'argument objet implicite de type cv T .
• Si l'expression E est une expression primaire , le nom est recherché suivant les règles normales pour les appels de fonction (ce qui peut impliquer une ADL ). Les déclarations de fonctions trouvées par cette recherche sont (en raison du fonctionnement de la recherche) soit :

• toutes les fonctions non-membres (auquel cas la liste d'arguments pour la résolution de surcharge est exactement la liste d'arguments utilisée dans l'expression d'appel de fonction)
• toutes les fonctions membres d'une classe T , auquel cas, si this est dans la portée et est un pointeur vers T ou vers une classe dérivée de T , * this est utilisé comme argument objet implicite. Sinon (si this n'est pas dans la portée ou ne pointe pas vers T ), un objet fictif de type T est utilisé comme argument objet implicite, et si la résolution de surcharge sélectionne ensuite une fonction membre non-statique, le programme est mal formé.

Appel à un objet de classe

Si E dans une expression d'appel de fonction E ( args ) a un type classe cv T , alors

• Les opérateurs d'appel de fonction de T sont obtenus par recherche ordinaire du nom operator ( ) dans le contexte de l'expression ( E ) . operator ( ) , et chaque déclaration trouvée est ajoutée à l'ensemble des fonctions candidates.
• Pour chaque fonction de conversion définie par l'utilisateur non explicit dans T ou dans une base de T (sauf si masquée), dont les qualificateurs cv sont identiques ou supérieurs à ceux de T , et où la fonction de conversion convertit vers :

• pointeur-vers-fonction
• référence-vers-pointeur-vers-fonction
• référence-vers-fonction

puis une fonction d'appel substitut avec un nom unique dont le premier paramètre est le résultat de la conversion, les paramètres restants sont la liste des paramètres acceptés par le résultat de la conversion, et le type de retour est le type de retour du résultat de la conversion, est ajoutée à l'ensemble des fonctions candidates. Si cette fonction substitut est sélectionnée par la résolution de surcharge ultérieure, alors la fonction de conversion définie par l'utilisateur sera appelée et ensuite le résultat de la conversion sera appelé.

Dans tous les cas, la liste d'arguments à des fins de résolution de surcharge est la liste d'arguments de l'expression d'appel de fonction précédée de l'argument objet implicite E (lors de la correspondance avec la fonction substitut, la conversion définie par l'utilisateur convertira automatiquement l'argument objet implicite en premier argument de la fonction substitut).

int f1(int);
int f2(float);
struct A
{
    using fp1 = int(*)(int);
    operator fp1() { return f1; } // fonction de conversion vers pointeur de fonction
    using fp2 = int(*)(float);
    operator fp2() { return f2; } // fonction de conversion vers pointeur de fonction
} a;
int i = a(1); // appelle f1 via le pointeur retourné par la fonction de conversion

Appel à un opérateur surchargé

Si au moins un des arguments d'un opérateur dans une expression a un type classe ou un type énumération, les opérateurs intégrés et les surcharges d'opérateurs définies par l'utilisateur participent à la résolution de surcharge, l'ensemble des fonctions candidates étant sélectionné comme suit :

Pour un opérateur unaire @ dont l'argument est de type T1 (après suppression des qualifications cv), ou un opérateur binaire @ dont l'opérande gauche est de type T1 et l'opérande droit de type T2 (après suppression des qualifications cv), les ensembles suivants de fonctions candidates sont préparés :

L'ensemble des fonctions candidates à soumettre pour la résolution de surcharge est une union des ensembles ci-dessus. La liste d'arguments pour la résolution de surcharge comprend les opérandes de l'opérateur, à l'exception de operator-> , où le second opérande n'est pas un argument pour l'appel de fonction (voir opérateur d'accès membre ).

struct A
{
    operator int();              // conversion définie par l'utilisateur
};
A operator+(const A&, const A&); // opérateur non-membre défini par l'utilisateur
void m()
{
    A a, b;
    a + b; // candidats membres : aucun
           // candidats non-membres : operator+(a, b)
           // candidats intégrés : int(a) + int(b)
           // la résolution de surcharge choisit operator+(a, b)
}

Si la résolution de surcharge sélectionne un candidat intégré, la séquence de conversion définie par l'utilisateur à partir d'un opérande de type classe n'est pas autorisée à avoir une seconde séquence de conversion standard : la fonction de conversion définie par l'utilisateur doit donner directement le type d'opérande attendu :

struct Y { operator int*(); }; // Y est convertible en int*
int *a = Y() + 100.0;          // erreur : aucun opérateur+ entre pointeur et double

Pour operator, , l'opérateur unaire operator & , et operator - > , s'il n'existe aucune fonction viable (voir ci-dessous) dans l'ensemble des fonctions candidates, alors l'opérateur est réinterprété comme un opérateur intégré.

Initialisation par constructeur

Lorsqu'un objet de type classe est direct-initialized ou default-initialized (y compris la default-initialization dans le contexte de copy-list-initialization ) (depuis C++11) , les fonctions candidates sont tous les constructeurs de la classe en cours d'initialisation. La liste d'arguments est la liste d'expressions de l'initialiseur.

Sinon, les fonctions candidates sont tous les constructeurs de conversion de la classe en cours d'initialisation. La liste d'arguments est l'expression de l'initialiseur.

Initialisation par copie via conversion

Si l'initialisation par copie d'un objet de type classe nécessite qu'une conversion définie par l'utilisateur soit appelée pour convertir l'expression d'initialisation de type cv S vers le type cv T de l'objet en cours d'initialisation, les fonctions suivantes sont des fonctions candidates :

• tous les constructeurs de conversion de T
• les fonctions de conversion non explicit de S et de ses classes de base (sauf si masquées) vers T ou une classe dérivée de T ou une référence à celles-ci. Si cette initialisation par copie fait partie de la séquence d'initialisation directe de cv T (initialisant une référence à lier au premier paramètre d'un constructeur qui prend une référence à cv T ), alors les fonctions de conversion explicites sont également considérées.

Dans tous les cas, la liste d'arguments à des fins de résolution de surcharge consiste en un seul argument qui est l'expression d'initialisation, qui sera comparée au premier argument du constructeur ou à l'argument objet implicite de la fonction de conversion.

Initialisation de non-classe par conversion

Lorsque l'initialisation d'un objet de type non-classe cv1 T nécessite une fonction de conversion définie par l'utilisateur pour convertir à partir d'une expression d'initialisation de type classe cv S , les fonctions suivantes sont candidates :

• les fonctions de conversion définies par l'utilisateur non-explicites de S et de ses classes de base (sauf si masquées) qui produisent le type T ou un type convertible en T par une séquence de conversion standard , ou une référence à un tel type. Les qualificateurs cv sur le type de retour sont ignorés pour la sélection des fonctions candidates.
• s'il s'agit d'une initialisation directe , les fonctions de conversion explicites définies par l'utilisateur de S et de ses classes de base (sauf si masquées) qui produisent le type T ou un type convertible en T par une conversion de qualification , ou une référence à un tel type, sont également considérées.

Dans tous les cas, la liste d'arguments à des fins de résolution de surcharge consiste en un seul argument qui est l'expression d'initialisation, qui sera comparée à l'argument objet implicite de la fonction de conversion.

Initialisation de référence par conversion

Lors de l'initialisation de référence , où la référence vers cv1 T est liée au résultat lvalue ou rvalue d'une conversion de l'expression d'initialisation du type classe cv2 S , les fonctions suivantes sont sélectionnées pour l'ensemble des candidats :

• Les fonctions de conversion définies par l'utilisateur non-explicites de S et de ses classes de base (sauf si masquées) vers le type

• (lors de la conversion en une lvalue) référence de lvalue vers cv2 T2
• (lors de la conversion en une rvalue ou une lvalue de type fonction) cv2 T2 ou référence de rvalue vers cv2 T2

où cv2 T2 est compatible avec les références avec cv1 T .

• Pour l'initialisation directe, les fonctions de conversion définies par l'utilisateur explicites sont également considérées si T2 est du même type que T ou peut être converti en type T avec une conversion de qualification.

Dans tous les cas, la liste d'arguments à des fins de résolution de surcharge consiste en un seul argument qui est l'expression d'initialisation, qui sera comparée à l'argument objet implicite de la fonction de conversion.

Initialisation par liste

Lorsqu'un objet de type classe non-aggregat T est initialisé par liste , une résolution de surcharge en deux phases a lieu.

• à la phase 1, les fonctions candidates sont tous les constructeurs de liste d'initialisation de T et la liste d'arguments pour la résolution de surcharge consiste en un seul argument de liste d'initialisation
• si la résolution de surcharge échoue à la phase 1, la phase 2 est entamée, où les fonctions candidates sont tous les constructeurs de T et la liste d'arguments pour la résolution de surcharge consiste en les éléments individuels de la liste d'initialisation.

Si la liste d'initialisation est vide et que T a un constructeur par défaut, la phase 1 est ignorée.

Dans l'initialisation de liste par copie, si la phase 2 sélectionne un constructeur explicite, l'initialisation est mal formée (contrairement à toutes les autres initialisations par copie où les constructeurs explicites ne sont même pas considérés).

Règles supplémentaires pour les candidats de modèles de fonction

Si la recherche de nom a trouvé un modèle de fonction, la déduction d'arguments de modèle et la vérification de tout argument de modèle explicite sont effectuées pour trouver les valeurs d'arguments de modèle (le cas échéant) qui peuvent être utilisées dans ce cas :

• Si les deux réussissent, les arguments du template sont utilisés pour synthétiser les déclarations des spécialisations de fonction template correspondantes, qui sont ajoutées à l'ensemble des candidats, et ces spécialisations sont traitées comme des fonctions non-template sauf indication contraire dans les règles de départage ci-dessous.
• Si la déduction d'arguments échoue ou si la spécialisation de fonction template synthétisée serait mal formée, aucune telle fonction n'est ajoutée à l'ensemble des candidats (voir SFINAE ).

Si un nom fait référence à une ou plusieurs fonctions modèles et également à un ensemble de fonctions non modèles surchargées, ces fonctions et les spécialisations générées à partir des modèles sont toutes des candidates.

Voir la surcharge de modèles de fonction pour plus de détails.

Règles supplémentaires pour les candidats constructeurs

Règles supplémentaires pour les candidats de fonctions membres

Si une fonction candidate est une fonction membre (statique ou non statique) qui ne possède pas de paramètre objet explicite (depuis C++23) , mais n'est pas un constructeur, elle est traitée comme si elle avait un paramètre supplémentaire ( paramètre objet implicite ) qui représente l'objet pour lequel elle est appelée et apparaît avant le premier des paramètres réels.

De même, l'objet sur lequel une fonction membre est appelée est ajouté au début de la liste d'arguments en tant que implied object argument .

Pour les fonctions membres de la classe X , le type du paramètre objet implicite est affecté par les qualifications cv et les qualifications de référence de la fonction membre comme décrit dans les fonctions membres .

Les fonctions de conversion définies par l'utilisateur sont considérées comme des membres de l' argument objet implicite aux fins de détermination du type du paramètre objet implicite .

Les fonctions membres introduites par une déclaration using dans une classe dérivée sont considérées comme des membres de la classe dérivée pour définir le type du paramètre objet implicite .

Pour le reste de la résolution de surcharge, l' argument objet implicite est indiscernable des autres arguments, mais les règles spéciales suivantes s'appliquent au paramètre objet implicite :

struct B { void f(int); };
struct A { operator B&(); };
A a;
a.B::f(1); // Error: user-defined conversions cannot be applied
           // to the implicit object parameter
static_cast<B&>(a).f(1); // OK

Fonctions viables

Étant donné l'ensemble des fonctions candidates, construit comme décrit ci-dessus, l'étape suivante de la résolution de surcharge consiste à examiner les arguments et paramètres pour réduire l'ensemble à l'ensemble des fonctions viables

Pour être incluse dans l'ensemble des fonctions viables, la fonction candidate doit satisfaire aux conditions suivantes :

Les conversions définies par l'utilisateur (à la fois les constructeurs de conversion et les fonctions de conversion définies par l'utilisateur) sont interdites de participer à une séquence de conversion implicite où cela rendrait possible l'application de plus d'une conversion définie par l'utilisateur. Plus précisément, elles ne sont pas considérées si la cible de la conversion est le premier paramètre d'un constructeur ou le paramètre objet implicite d'une fonction de conversion définie par l'utilisateur, et que ce constructeur/fonction de conversion définie par l'utilisateur est un candidat pour

• copie-initialisation d'une classe par conversion définie par l'utilisateur ,
• initialisation d'un type non-classe par une fonction de conversion ,
• initialisation par fonction de conversion pour la liaison directe de référence ,
• initialisation par constructeur durant la seconde étape (initialisation directe) de la copie-initialisation de classe,

struct A { A(int); };
struct B { B(A); };
B b{{0}}; // list-initialization of B
// candidates: B(const B&), B(B&&), B(A)
// {0} -> B&& not viable: would have to call B(A)
// {0} -> const B&: not viable: would have to bind to rvalue, would have to call B(A)
// {0} -> A viable. Calls A(int): user-defined conversion to A is not banned

Fonction viable optimale

Pour chaque paire de fonctions viables F1 et F2 , les séquences de conversion implicite du i ^ième argument vers le i ^ième paramètre sont classées pour déterminer laquelle est meilleure (sauf le premier argument, l' argument objet implicite pour les fonctions membres statiques n'a aucun effet sur le classement)

F1 est déterminée comme étant une meilleure fonction que F2 si les conversions implicites pour tous les arguments de F1 sont pas pires que les conversions implicites pour tous les arguments de F2, et

template<typename T = int>
struct S
{
    constexpr void f(); // #1
    constexpr void f(this S&) requires true; // #2
};
void test()
{
    S<> s;
    s.f(); // calls #2
}

struct A
{
    A(int = 0);
};
struct B: A
{
    using A::A;
    B();
};
B b; // OK, B::B()

template<class T>
struct A
{
    using value_type = T;
    A(value_type);  // #1
    A(const A&);    // #2
    A(T, T, int);   // #3
    template<class U>
    A(int, T, U);   // #4
};                  // #5 est A(A), le candidat de déduction de copie
A x(1, 2, 3); // utilise #3, généré à partir d'un constructeur non template
template<class T>
A(T) -> A<T>;       // #6, moins spécialisé que #5
A a (42); // utilise #6 pour déduire A<int> et #1 pour initialiser
A b = a;  // utilise #5 pour déduire A<int> et #2 pour initialiser
template<class T>
A(A<T>) -> A<A<T>>; // #7, aussi spécialisé que #5
A b2 = a; // utilise #7 pour déduire A<A<int>> et #1 pour initialiser

Ces comparaisons par paires sont appliquées à toutes les fonctions viables. Si exactement une fonction viable est meilleure que toutes les autres, la résolution de surcharge réussit et cette fonction est appelée. Sinon, la compilation échoue.

void Fcn(const int*, short); // surcharge #1
void Fcn(int*, int);         // surcharge #2
int i;
short s = 0;
void f() 
{
    Fcn(&i, 1L);  // 1er argument : &i -> int* est meilleur que &i -> const int*
                  // 2ème argument : 1L -> short et 1L -> int sont équivalents
                  // appelle Fcn(int*, int)
    Fcn(&i, 'c'); // 1er argument : &i -> int* est meilleur que &i -> const int*
                  // 2ème argument : 'c' -> int est meilleur que 'c' -> short
                  // appelle Fcn(int*, int)
    Fcn(&i, s);   // 1er argument : &i -> int* est meilleur que &i -> const int*
                  // 2ème argument : s -> short est meilleur que s -> int
                  // aucun gagnant, erreur de compilation
}

Si la meilleure fonction viable résout à une fonction pour laquelle plusieurs déclarations ont été trouvées, et si deux quelconques de ces déclarations se trouvent dans des portées différentes et spécifient un argument par défaut qui a rendu la fonction viable, le programme est mal formé.

namespace A
{
    extern "C" void f(int = 5);
}
namespace B
{
    extern "C" void f(int = 5);
}
using A::f;
using B::f;
void use()
{
    f(3); // OK, l'argument par défaut n'a pas été utilisé pour la viabilité
    f();  // erreur : argument par défaut trouvé deux fois
}

Classement des séquences de conversion implicite

Les séquences de conversion implicite argument-paramètre considérées par la résolution de surcharge correspondent aux conversions implicites utilisées dans l' initialisation par copie (pour les paramètres non-référence), sauf que lors de la considération de la conversion vers le paramètre objet implicite ou vers le côté gauche de l'opérateur d'affectation, les conversions qui créent des objets temporaires ne sont pas considérées. Lorsque le paramètre est le paramètre objet implicite d'une fonction membre statique, la séquence de conversion implicite est une séquence de conversion standard qui n'est ni meilleure ni pire qu'aucune autre séquence de conversion standard. (depuis C++23)

Chaque type de séquence de conversion standard se voit attribuer l'un des trois rangs :

Le rang de la séquence de conversion standard est le pire des rangs des conversions standards qu'elle contient (il peut y avoir jusqu'à trois conversions )

La liaison d'un paramètre de référence directement à l'expression d'argument est soit une identité soit une conversion dérivée-vers-base :

struct Base {};
struct Derived : Base {} d;
int f(Base&);    // surcharge #1
int f(Derived&); // surcharge #2
int i = f(d); // d -> Derived& a le rang Correspondance Exacte
              // d -> Base& a le rang Conversion
              // appelle f(Derived&)

Puisque le classement des séquences de conversion opère uniquement avec des types et des catégories de valeur, un bit field peut se lier à un argument de référence pour les besoins du classement, mais si cette fonction est sélectionnée, elle sera mal formée.

int i;
int f1();
int g(const int&);  // surcharge #1
int g(const int&&); // surcharge #2
int j = g(i);    // lvalue int -> const int& est la seule conversion valide
int k = g(f1()); // rvalue int -> const int&& meilleure que rvalue int -> const int&

int f(void(&)());  // surcharge #1
int f(void(&&)()); // surcharge #2
void g();
int i1 = f(g); // appelle #1

int f(const int*);
int f(int*);
int i;
int j = f(&i); // &i -> int* est meilleur que &i -> const int*, appelle f(int*)

int f(const int &); // surcharge #1
int f(int &);       // surcharge #2 (les deux références)
int g(const int &); // surcharge #1
int g(int);         // surcharge #2
int i;
int j = f(i); // lvalue i -> int& est meilleur que lvalue int -> const int&
              // appelle f(int&)
int k = g(i); // lvalue i -> const int& classe Correspondance Exacte
              // lvalue i -> rvalue int classe Correspondance Exacte
              // surcharge ambiguë : erreur de compilation

struct Z {};
struct A
{
    operator Z&();
    operator const Z&();  // surcharge #1
};
struct B
{
    operator Z();
    operator const Z&&(); // surcharge #2
};
const Z& r1 = A();        // OK, utilise #1
const Z&& r2 = B();       // OK, utilise #2

struct A
{
    operator short(); // fonction de conversion définie par l'utilisateur
} a;
int f(int);   // surcharge #1
int f(float); // surcharge #2
int i = f(a); // A -> short, suivi de short -> int (rang Promotion)
              // A -> short, suivi de short -> float (rang Conversion)
              // appelle f(int)

void f1(int);                                 // #1
void f1(std::initializer_list<long>);         // #2
void g1() { f1({42}); }                       // choisit #2
void f2(std::pair<const char*, const char*>); // #3
void f2(std::initializer_list<std::string>);  // #4
void g2() { f2({"foo", "bar"}); }             // choisit #4

void f(int    (&&)[] ); // overload #1
void f(double (&&)[] ); // overload #2
void f(int    (&&)[2]); // overload #3
f({1});        // #1: Better than #2 due to conversion, better than #3 due to bounds
f({1.0});      // #2: double -> double is better than double -> int
f({1.0, 2.0}); // #2: double -> double is better than double -> int
f({1, 2});     // #3: -> int[2] is better than -> int[], 
               //     and int -> int is better than int -> double

Si deux séquences de conversion sont indiscernables parce qu'elles ont le même rang, les règles supplémentaires suivantes s'appliquent :

enum num : char { one = '0' };
std::cout << num::one; // '0', not 48

int f(std::float32_t);
int f(std::float64_t);
int f(long long);
float x;
std::float16_t y;
int i = f(x); // appelle f(std::float32_t) sur les implémentations où
              // float et std::float32_t ont des rangs de conversion égaux
int j = f(y); // erreur : ambigu, pas de rang de conversion égal

Les séquences de conversion ambiguës sont classées comme des séquences de conversion définies par l'utilisateur car plusieurs séquences de conversion pour un argument ne peuvent exister que si elles impliquent différentes conversions définies par l'utilisateur :

class B;
class A { A (B&);};         // constructeur de conversion
class B { operator A (); }; // fonction de conversion définie par l'utilisateur
class C { C (B&); };        // constructeur de conversion
void f(A) {} // surcharge #1
void f(C) {} // surcharge #2
B b;
f(b); // B -> A via ctor ou B -> A via fonction (conversion ambiguë)
      // b -> C via ctor (conversion définie par l'utilisateur)
      // les conversions pour la surcharge #1 et pour la surcharge #2
      // sont indiscernables ; la compilation échoue

Séquence de conversion implicite dans l'initialisation de liste

Dans l'initialisation par liste , l'argument est un braced-init-list , qui n'est pas une expression, donc la séquence de conversion implicite vers le type du paramètre pour la résolution de surcharge est déterminée par les règles spéciales suivantes :

• Si le type du paramètre est un agrégat X et que la liste d'initialisation contient exactement un élément de même classe ou d'une classe dérivée (éventuellement qualifiée cv), la séquence de conversion implicite est celle requise pour convertir l'élément au type du paramètre.
• Sinon, si le type du paramètre est une référence à un tableau de caractères et que la liste d'initialisation possède un seul élément qui est un littéral de chaîne de type approprié, la séquence de conversion implicite est la conversion identité.
• Sinon, si le type du paramètre est std:: initializer_list < X > , et qu'il existe une conversion implicite non rétrécissante de chaque élément de la liste d'initialisation vers X , la séquence de conversion implicite pour la résolution de surcharge est la pire conversion nécessaire. Si la liste d'initialisation entre accolades est vide, la séquence de conversion est la conversion identité.

struct A
{
    A(std::initializer_list<double>);          // #1
    A(std::initializer_list<complex<double>>); // #2
    A(std::initializer_list<std::string>);     // #3
};
A a{1.0, 2.0};     // sélectionne #1 (rvalue double -> double : conversion identité)
void g(A);
g({"foo", "bar"}); // sélectionne #3 (lvalue const char[4] -> std::string : conversion définie par l'utilisateur)

• Sinon, si le type du paramètre est « tableau de N T » (cela ne se produit que pour les références à des tableaux), la liste d'initialisation doit avoir N éléments ou moins, et la pire conversion implicite nécessaire pour convertir chaque élément de la liste (ou la paire vide d'accolades {} si la liste est plus courte que N) en T est celle utilisée.

typedef int IA[3];
void h(const IA&);
void g(int (&&)[]);
h({1, 2, 3}); // conversion identité int->int
g({1, 2, 3}); // identique depuis C++20

• Sinon, si le type du paramètre est un type de classe non-agrégé X , la résolution de surcharge sélectionne le constructeur C de X pour l'initialiser à partir de la liste d'initialisation d'arguments

• Si C n'est pas un constructeur de liste d'initialisation et que la liste d'initialisation a un seul élément de type X éventuellement qualifié cv, la séquence de conversion implicite a le rang Exact Match. Si la liste d'initialisation a un seul élément de type dérivé de X éventuellement qualifié cv, la séquence de conversion implicite a le rang Conversion. (notez la différence avec les agrégats : les agrégats s'initialisent directement depuis les listes d'initialisation à un seul élément avant de considérer l'initialisation d'agrégat , les non-agrégats considèrent les constructeurs initializer_list avant tout autre constructeur)
• sinon, la séquence de conversion implicite est une séquence de conversion définie par l'utilisateur avec la deuxième séquence de conversion standard étant une conversion identité.

Si plusieurs constructeurs sont viables mais qu'aucun n'est meilleur que les autres, la séquence de conversion implicite est la séquence de conversion ambiguë.

struct A { A(std::initializer_list<int>); };
void f(A);
struct B { B(int, double); };
void g(B);
g({'a', 'b'});    // appelle g(B(int, double)), conversion définie par l'utilisateur
// g({1.0, 1,0}); // erreur : double->int est un rétrécissement, non autorisé dans l'initialisation par liste
void f(B);
// f({'a', 'b'}); // f(A) et f(B) sont toutes deux des conversions définies par l'utilisateur

• Sinon, si le type du paramètre est un agrégat qui peut être initialisé à partir de la liste d'initialisation selon l'initialisation d'agrégat , la séquence de conversion implicite est une séquence de conversion définie par l'utilisateur avec la deuxième séquence de conversion standard étant une conversion identité.

struct A { int m1; double m2; };
void f(A);
f({'a', 'b'}); // appelle f(A(int, double)), conversion définie par l'utilisateur

• Sinon, si le paramètre est une référence, les règles d'initialisation des références s'appliquent

struct A { int m1; double m2; };
void f(const A&);
f({'a', 'b'}); // temporaire créé, f(A(int, double)) appelé. Conversion définie par l'utilisateur

• Sinon, si le type du paramètre n'est pas une classe et que la liste d'initialisation a un élément, la séquence de conversion implicite est celle requise pour convertir l'élément en type de paramètre
• Sinon, si le type du paramètre n'est pas un type classe et si la liste d'initialisation n'a aucun élément, la séquence de conversion implicite est la conversion identité.

struct A { int x, y; };
struct B { int y, x; };
void f(A a, int); // #1
void f(B b, ...); // #2
void g(A a);      // #3
void g(B b);      // #4
void h() 
{
    f({.x = 1, .y = 2}, 0); // OK; calls #1
    f({.y = 2, .x = 1}, 0); // error: selects #1, initialization of a fails
                            // due to non-matching member order
    g({.x = 1, .y = 2});    // error: ambiguous between #3 and #4
}

Rapports de défauts

Les rapports de défauts modifiant le comportement suivants ont été appliqués rétroactivement aux normes C++ précédemment publiées.

1. ↑ Le type du premier paramètre d'un opérateur d'affectation intégré est « référence à lvalue vers T éventuellement qualifié volatile ». Les références de ce type ne peuvent pas être liées à un temporaire.

Références

Voir aussi

• Recherche de nom
• Recherche dépendante des arguments
• Déduction d'arguments de template
• SFINAE