2010-05-26 16 views
4

Ceci est une suite à my previous question.Un suivi de la coercition de type en C++, tel qu'il peut être interprété par conversion de type

Tenir compte que j'écris une fonction avec le prototype suivant:

int a_function(Foo val); 

Où foo est considéré comme un type défini unsigned int. Ceci n'est malheureusement pas vérifiable par manque de documentation. Donc, quelqu'un arrive et utilise une fonction, mais l'appelle avec un int non signé en tant qu'argument.

Ici l'histoire prend un tour. Foo s'avère être une classe, qui peut prendre un int non-signé comme un seul argument de unsigned int dans un constructeur explicite.

Est-ce un comportement standard et fiable pour le compilateur de rendre l'appel de fonction en effectuant une conversion de type sur l'argument. C'est à dire. le compilateur est-il censé reconnaître la discordance et insérer le constructeur? Ou devrais-je obtenir une erreur de compilation rapportant la différence de type.

Répondre

6

Dans le cas où Foo a un constructeur pour unsigned int, une conversion implicite aura lieu à moins que Foo ne soit déclaré explicite.

Le premier cas:

class Foo { public: Foo(unsigned int) {} }; 
// ... 
a_function(1); // OK 

Deuxième cas:

class Foo { public: explicit Foo(unsigned int) {} }; 
// .. 
a_function(1); // error 

Selon la norme C++ une seule conversion implicite définie par l'utilisateur est autorisé.

0

Oui, il est correct que le compilateur fasse la conversion de type comme ça. Si ce n'était pas le cas, des choses comme des constructeurs de conversion ou une conversion implicite ne seraient pas possibles.

Il est préférable d'éviter que de telles choses ne se produisent par le biais de bonnes pratiques et de documentation dont votre fonction semble souffrir.

0

Si le constructeur est explicit alors a_function(50U); résulterait en une erreur de compilation tandis que a_function(Foo(50U)); fonctionnerait.

Cette fonctionnalité est dans le langage pour empêcher exactement ce genre de conversion accidentelle.