Les autres réponses ici va résoudre le problème, mais ce qui suit est le modèle que je l'utilise quand je fais ceci:
class Num
{
public:
Num(int i) // Not explicit, allows implicit conversion to Num
: i_ (i)
{
}
Num (Num const & rhs)
: i_ (rhs.i_)
{
}
Num & operator+= (Num const & rhs) // Implement +=
{
i_ += rhs.i_;
return *this;
}
private:
int i_;
};
//
// Because of Num(int), any number on the LHS or RHS will implicitly
// convert to Num - so no need to have lots of overloads
Num operator+(Num const & lhs, Num const & rhs)
{
//
// Implement '+' using '+='
Num tmp (lhs);
tmp+=rhs;
return tmp;
}
L'un des principaux avantages de cette approche est que vos fonctions peut être implémenté en termes de réduction de la quantité de code global dont vous avez besoin.
MISE À JOUR:
Pour garder les problèmes de performances à distance, je définirais probablement l'opérateur non membre + comme quelque chose comme la fonction en ligne:
inline Num operator+(Num lhs, Num const & rhs)
{
lhs+=rhs;
return lhs;
}
Les opérations membres sont également en ligne (comme ils 're déclaré dans le corps de la classe) et donc dans tout le code devrait être très proche du coût de l'ajout de deux objets int
premières. Enfin, comme le souligne jalf, les conséquences de l'autorisation de conversions implicites en général doivent être prises en compte. L'exemple ci-dessus suppose qu'il est judicieux de convertir un type intégral en un 'Num'.
+1. Vous devriez quand même préférer les versions non-membres, même dans les cas où cela n'est pas nécessaire. N'utilisez les variantes de membre que lorsque cela est nécessaire. – jalf
Je préfère toujours me lier d'amitié avec mes opérateurs non-membres. –