Pourquoi ne pas déduire le paramètre de modèle du constructeur?

ma question aujourd'hui est assez simple: pourquoi le compilateur ne peut-il pas déduire les paramètres de modèle à partir des constructeurs de classe, autant qu'il peut le faire à partir des paramètres de fonction? Par exemple, pourquoi le code suivant ne pourrait-il pas être valide:

template<typename obj>
class Variable {
      obj data;
      public: Variable(obj d)
              {
                   data = d;
              }
};

int main()
{
    int num = 2;
    Variable var(num); //would be equivalent to Variable<int> var(num),
    return 0;          //but actually a compile error
}

Comme je l'ai dit, je comprends que ce n'est pas valide, alors ma question est de savoir pourquoi n'est-ce pas? Autoriser cela créerait-il des trous syntaxiques majeurs? Existe-t-il une instance où l'on ne voudrait pas de cette fonctionnalité (où inférer un type causerait des problèmes)? J'essaie juste de comprendre la logique derrière l'autorisation de l'inférence de modèle pour les fonctions, mais pas pour les classes correctement construites.

Je pense que ce n'est pas valide car le constructeur n'est pas toujours le seul point d'entrée de la classe (je parle de constructeur de copie et d'opérateur =). Supposons donc que vous utilisiez votre classe comme ceci:

MyClass m(string s);
MyClass *pm;
*pm = m;

Je ne sais pas s'il serait si évident pour l'analyseur de savoir quel type de modèle est MyClass pm;

Je ne sais pas si ce que j'ai dit a du sens, mais n'hésitez pas à ajouter quelques commentaires, c'est une question intéressante.

C ++ 17

Il est admis que C ++ 17 aura une déduction de type à partir des arguments du constructeur.

Exemples:

std::pair p(2, 4.5);
std::tuple t(4, 3, 2.5);

Papier accepté .

Vous ne pouvez pas faire ce que vous demandez pour les raisons que d'autres personnes ont adressées, mais vous pouvez le faire:

template<typename T>
class Variable {
    public: Variable(T d) {}
};
template<typename T>
Variable<T> make_variable(T instance) {
  return Variable<T>(instance);
}

ce qui à toutes fins utiles est la même chose que vous demandez. Si vous aimez l'encapsulation, vous pouvez faire de make_variable une fonction membre statique. C'est ce que les gens appellent constructeur nommé. Donc, non seulement il fait ce que vous voulez, mais il s'appelle presque ce que vous voulez: le compilateur déduit le paramètre de modèle du constructeur (nommé).

NB: tout compilateur raisonnable optimisera l'objet temporaire lorsque vous écrivez quelque chose comme

auto v = make_variable(instance);

À l'ère éclairée de 2016, avec deux nouvelles normes à notre actif depuis que cette question a été posée et une nouvelle juste au coin de la rue, la chose cruciale à savoir est que les compilateurs prenant en charge la norme C ++ 17 compileront votre code tel quel. .

Déduction d'argument de modèle pour les modèles de classe en C ++ 17

Voici (grâce à une modification par Olzhas Zhumabek de la réponse acceptée) le document détaillant les changements pertinents apportés à la norme.

Répondre aux préoccupations d'autres réponses

La réponse actuelle la mieux notée

Cette réponse souligne que "copier le constructeur et operator=" ne connaîtrait pas les spécialisations de modèle correctes.

C'est absurde, car le constructeur de copie standard operator= n'existe que pour un type de modèle connu :

template <typename T>
class MyClass {
    MyClass(const MyClass&) =default;
    ... etc...
};

// usage example modified from the answer
MyClass m(string("blah blah blah"));
MyClass *pm;   // WHAT IS THIS?
*pm = m;

Ici, comme je l' ai mentionné dans les commentaires, il n'y a aucune raison pour MyClass *pmêtre une déclaration juridique avec ou sans la nouvelle forme d'inférence: MyClass n'est pas un type (il est un modèle), il n'a pas de sens de déclarer un pointeur de type MyClass. Voici une façon possible de corriger l'exemple:

MyClass m(string("blah blah blah"));
decltype(m) *pm;               // uses type inference!
*pm = m;

Ici, pmest déjà du type correct, et donc l'inférence est triviale. De plus, il est impossible de mélanger accidentellement des types lors de l'appel du constructeur de copie:

MyClass m(string("blah blah blah"));
auto pm = &(MyClass(m));

Ici, pmsera un pointeur vers une copie de m. Ici, MyClassest en cours de construction de copie - mqui est de type MyClass<string>(et non de type inexistant MyClass). Ainsi, au moment où pmle type de s est déduit, il y a suffisamment d'informations pour savoir que le type de modèle de m, et donc le type de modèle de pm, est string.

De plus, ce qui suit provoquera toujours une erreur de compilation :

MyClass s(string("blah blah blah"));
MyClass i(3);
i = s;

C'est parce que la déclaration du constructeur de copie n'est pas basée sur un modèle:

MyClass(const MyClass&);

Ici, le type de modèle de l'argument du constructeur de copie correspond au type de modèle de la classe dans son ensemble; c'est-à-dire, quand MyClass<string>est instancié, MyClass<string>::MyClass(const MyClass<string>&);est instancié avec lui, et quand MyClass<int>est instancié, MyClass<int>::MyClass(const MyClass<int>&);est instancié. À moins qu'il ne soit explicitement spécifié ou qu'un constructeur basé sur un modèle soit déclaré, il n'y a aucune raison pour que le compilateur instancie MyClass<int>::MyClass(const MyClass<string>&);, ce qui serait évidemment inapproprié.

La réponse de Cătălin Pitiș

Pitiș donne un exemple en déduisant Variable<int>et Variable<double>, puis déclare:

J'ai le même nom de type (variable) dans le code pour deux types différents (variable et variable). De mon point de vue subjectif, cela affecte sensiblement la lisibilité du code.

Comme indiqué dans l'exemple précédent, Variable lui-même n'est pas un nom de type, même si la nouvelle fonctionnalité le fait ressembler syntaxiquement.

Pitiș demande alors ce qui se passerait si aucun constructeur n'est donné qui permettrait l'inférence appropriée. La réponse est qu'aucune inférence n'est autorisée, car l'inférence est déclenchée par l' appel du constructeur . Sans appel de constructeur, il y a pas d'inférence .

Cela revient à demander quelle version de fooest déduite ici:

template <typename T> foo();
foo();

La réponse est que ce code est illégal, pour la raison indiquée.

Réponse de MSalter

C'est, pour autant que je sache, la seule réponse pour soulever une préoccupation légitime concernant la fonctionnalité proposée.

L'exemple est:

Variable var(num);  // If equivalent to Variable<int> var(num),
Variable var2(var); // Variable<int> or Variable<Variable<int>> ?

La question clé est la suivante: le compilateur sélectionne-t -il ici le constructeur déduit du type ou la copie constructeur de ?

En essayant le code, nous pouvons voir que le constructeur de copie est sélectionné. Pour développer l'exemple :

Variable var(num);          // infering ctor
Variable var2(var);         // copy ctor
Variable var3(move(var));   // move ctor
// Variable var4(Variable(num));     // compiler error

Je ne sais pas comment la proposition et la nouvelle version de la norme le précisent; il semble être déterminé par des «guides de déduction», qui sont un nouveau morceau de standard que je ne comprends pas encore.

Je ne sais pas non plus pourquoi la var4déduction est illégale; l'erreur du compilateur de g ++ semble indiquer que l'instruction est analysée comme une déclaration de fonction.

Toujours manquant: cela rend le code suivant assez ambigu:

int main()
{
    int num = 2;
    Variable var(num);  // If equivalent to Variable<int> var(num),
    Variable var2(var); //Variable<int> or Variable<Variable<int>> ?
}

Supposons que le compilateur supporte ce que vous avez demandé. Alors ce code est valide:

Variable v1( 10); // Variable<int>

// Some code here

Variable v2( 20.4); // Variable<double>

Maintenant, j'ai le même nom de type (Variable) dans le code pour deux types différents (Variable et Variable). De mon point de vue subjectif, cela affecte sensiblement la lisibilité du code. Avoir le même nom de type pour deux types différents dans le même espace de noms me semble trompeur.

Mise à jour ultérieure: Autre chose à considérer: la spécialisation partielle (ou complète) des modèles.

Et si je me spécialise dans Variable et que je ne fournis aucun constructeur comme prévu?

Donc j'aurais:

template<>
class Variable<int>
{
// Provide default constructor only.
};

Ensuite, j'ai le code:

Variable v( 10);

Que doit faire le compilateur? Utilisez la définition de classe Variable générique pour déduire qu'il s'agit d'une variable, puis découvrez que Variable ne fournit pas un constructeur de paramètre?

Le C ++ 03 et le standard C ++ 11 n'autorisent pas la déduction d'arguments de modèle à partir des paramètres passés au constructeur.

Mais il existe une proposition de "Déduction de paramètres de modèle pour les constructeurs" afin que vous obteniez bientôt ce que vous demandez. Edit: en effet, cette fonctionnalité a été confirmée pour C ++ 17.

Voir: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3602.html et http://www.open-std.org/jtc1/sc22/wg21/docs/ papiers / 2015 / p0091r0.html

De nombreuses classes ne dépendent pas des paramètres du constructeur. Il n'y a que quelques classes qui n'ont qu'un seul constructeur et qui sont paramétrées en fonction du ou des types de ce constructeur.

Si vous avez vraiment besoin d'une inférence de modèle, utilisez une fonction d'assistance:

template<typename obj>
class Variable 
{
      obj data;
public: 
      Variable(obj d)
      : data(d)
      { }
};

template<typename obj>
inline Variable<obj> makeVariable(const obj& d)
{
    return Variable<obj>(d);
}

La déduction des types est limitée aux fonctions de modèle dans le C ++ actuel, mais on s'est rendu compte depuis longtemps que la déduction de types dans d'autres contextes serait très utile. D'où C ++ 0x auto.

Bien que ce que vous suggérez ne soit pas possible en C ++ 0x, ce qui suit montre que vous pouvez vous en approcher assez:

template <class X>
Variable<typename std::remove_reference<X>::type> MakeVariable(X&& x)
{
    // remove reference required for the case that x is an lvalue
    return Variable<typename std::remove_reference<X>::type>(std::forward(x));
}

void test()
{
    auto v = MakeVariable(2); // v is of type Variable<int>
}

Vous avez raison, le compilateur pourrait facilement deviner, mais ce n'est pas dans la norme ou C ++ 0x pour autant que je sache, vous devrez donc attendre au moins 10 ans de plus (taux de rotation fixe des normes ISO) avant que les fournisseurs de compilateurs ajoutent cette fonctionnalité

Regardons le problème en référence à une classe que tout le monde devrait connaître - std :: vector.

Tout d'abord, une utilisation très courante du vecteur est d'utiliser le constructeur qui ne prend aucun paramètre:

vector <int> v;

Dans ce cas, évidemment aucune inférence ne peut être effectuée.

Une deuxième utilisation courante consiste à créer un vecteur prédimensionné:

vector <string> v(100);

Ici, si l'inférence était utilisée:

vector v(100);

nous obtenons un vecteur d'entiers, pas de chaînes, et vraisemblablement il n'est pas dimensionné!

Enfin, considérez les constructeurs qui acceptent plusieurs paramètres - avec "inférence":

vector v( 100, foobar() );      // foobar is some class

Quel paramètre doit être utilisé pour l'inférence? Nous aurions besoin d'un moyen de dire au compilateur que ce devrait être le deuxième.

Avec tous ces problèmes pour une classe aussi simple que vectorielle, il est facile de comprendre pourquoi l'inférence n'est pas utilisée.

Faire du ctor un modèle la Variable ne peut avoir qu'une seule forme mais plusieurs cteurs:

class Variable {
      obj data; // let the compiler guess
      public:
      template<typename obj>
      Variable(obj d)
       {
           data = d;
       }
};

int main()
{
    int num = 2;
    Variable var(num);  // Variable::data int?

    float num2 = 2.0f;
    Variable var2(num2);  // Variable::data float?
    return 0;         
}

Voir? Nous ne pouvons pas avoir plusieurs membres Variable :: data.

Voir la déduction d'argument de modèle C ++ pour plus d'informations à ce sujet.