question redefinition "operator ="

Bonjour,

Si on définit une classe

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class nouveau_type { private: int m_valeur; public: nouveau_type& operator=(nouveau_type const &val) { this->m_valeur=val; return(*this); } };

---

Avec la redéfinition de l'opérateur= comme précédent, il est donc possible d'effectuer l'opération suivante:

nouveau_type A = 7; //équivalent a A.m_valeur = 7;

J'en arrive donc a ma question===>
est il possible de faire l'inverse? :aie:

cad redéfinir l'opérateur= "standard"(agissant sur les types int/float/short/etc)...de telle sorte que le compilateur comprenne que

(int = nouveau_type) est équivalent à (int = nouveau_type.m_valeur)

(je pense à une redéfinition comme pour l'opérateur std::operator<< :?)

Merci d'avance de vos idées!

(Pour l'instant j'utilise une fonction "to_float" qui me retourne la valeur, mais ca complique la prog et la lisibilité, c'est quand meme plus joli un "=" transparent!)

oui tu peux regarder les operateurs de cast

Code:

---

1 2 3 4 5 6 7

class mon_type { operator int() { return m_value; } };   mon_type a = 7; int x = a;

---

bien merci screetch!

je savais pas que ca existait cette possibilité :yaisse2:

ca marche avec tous les types!

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

operator unsigned char() { return (this->m_pt_float.to_float()); }   operator signed char() { return (this->m_pt_float.to_float()); } operator unsigned short() { return (this->m_pt_float.to_float()); } operator signed short() { return (this->m_pt_float.to_float()); } operator unsigned long() { return (this->m_pt_float.to_float()); } operator float() { return (this->m_pt_float.to_float()); } operator int() { return (this->m_pt_float.to_float()); }

---

Les conversions implicites, c'est dangereux, car tu peux te retrouver avec des valeurs bizarres sans svaoir d'où elle viennent.

Citation:

---

Envoyé par Davidbrcz

Les conversions implicites, c'est dangereux

---

Dangereux, le mot est peut-être fort mais ça fini par poser des problèmes quand on ne restreint pas leur utilisation.

En passant, loicounet, tu abuses de this et les conversions implicites qui ne sont pas const, ça me semble avoir guère de sens.

On me le dit tout le temps, n'y va pas à la hache. C'est vrai je prend la bombe A.

Disons que les conversion implicites, si c'est mal gérées , ca te fout un bordel pas possible, la plus part du temps, pour un service rendu assez faible.

oui ca fait barbare comme conversion, je vais rajouter un test avec un cerr<< si on dépasse la plage de représentation!

pour le this c'est vrai que c'est inutile...

Ce qui est dommage, c'est qu'on ne peut pas déclarer explicit ces opérateurs de conversion...

:mouarf:

justement je cherchais dans mon bouquin pour voir si ya moyen de faire les opérateur de cast explicite
==>
bon ben si ca existe pas je vais arrêter de chercher ca alors!

J'ai vu aussi qu'une façon d'éviter les utilisations abusives (à l'insu de notre plein gré comme disait un certain cycliste) est de bien redéfinir tous les opérateurs de la classe (+,-,*,/,+=,-=,*=,/=,++,--,<<,>>,<<=,>>=, !=,>,<,<=,>=,==,...)

Apparemment lorsque le compilo arrive sur une opération il cherche en premier s'il existe un opérateur redéfini, puis s'il ne trouve pas il tente la conversion...
(à partir de la on voit clairement que l'autorisation de cast peut autoriser des opérations qui n'étaient pas possible et qui le devienne!)


exemple:
J'ai commenté ma redéfinition de l'operation addition de:
mon_type operateur+(int op1, mon_type op2)

avant que je definisse le cast "operator int() ", le compilo beuglait
après définition, op2 est convertit!

oula...:aie: terrain glissant!

ah c'est ma faute c'est moi qui ait oublié le const en haut.

* court se fouetter avec un emballage de snickers