Convertion implicite des paramètres des constructeurs d'une classe.

Bonjour.

Problème dont la réponse doit être toute simple mais que je ne connais pas.

J'ai une classe Color.

Elle possède les constructeurs :

Code:

---

1 2	Color(unsigned char red, unsigned char green, unsigned char blue, unsigned char alpha = 255); Color(float red, float green, float blue, float alpha = 1.f);

---

Pour le premier constructeur, on s'attend à ce que la couleur soit construite comme ça : Color red(255, 0, 0);

Dans le deuxième, elle est construite comme ça : Color red(1.f, 0.f, 0.f);

Or, dans le premier cas Color red(255, 0, 0), le compilateur ne sais pas quelle constructeur utiliser :

Code:

---

1 2 3 4

1>..\src\ExEngine\Graphics\Color.cpp(17) : error C2668: 'ex::Color::Color' : ambiguous call to overloaded function 1> D:\Excellence\include\ExEngine/Graphics/Color.hpp(15): could be 'ex::Color::Color(float,float,float,float)' 1> D:\Excellence\include\ExEngine/Graphics/Color.hpp(14): or 'ex::Color::Color(sf::Uint8,sf::Uint8,sf::Uint8,sf::Uint8)' 1> while trying to match the argument list '(int, int, int)'

---

Quelle solution puis-je utiliser pour que le compilo puisse deviner quel constructeur utiliser, suivant que j'utilise des uchar ou des float?

Je bosse sous Visual Studio 2008

Un petit coup de SFINAE:

Code:

---

1 2 3 4 5 6

template<class T> Color( T r, T g, T b, T alpha = T(255), typename boost::enable_if< boost::is_integral<T> >::type* = 0 );   template<class T> Color( T r, T g, T b, T alpha = T(1.f), typename boost::enable_if< boost::is_floating_point<T> >::type* = 0 );

---

Il n'y a pas un moyen plus simple et sans passer par boost? :/

Non. Et va falloir arreter avec cette phobie de boost.

J'ai trouvé une autre solution :

Je déclare deux classe, une Coloruc avec un constructeur Coloruc (unsigned char r, unsigned char g, unsigned char b, unsigned char a), ma classe Color avec un constructeur Color(const Coloruc & color) et son constructeur en float, et avec la conversion implicit, il accept que je fasse Color red(255, 0, 0).

Ca impose une construction supplémentaire, mais ça marche.

I beg to differ :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

struct foo { foo( int,int,int,int ) { cout << "foo\n"; } };   struct bar { bar(float,float,float,float) { cout << "bar\n"; } bar( foo const& ) { cout << "foo in bar\n"; } };   int main() { bar b(1,2,3,4); bar c(1.f,2.f,3.f,0.f); }

---

Sortie :

Citation:

---

bar
bar

---

True, bon ben boost, sinon convertion explicit.

Dans le même esprit, que se passe-t-il si on appelle ce constructeur boosté avec des arguments de type différent ?

Code:

---

Color( 1.0, 1.0, 1, 1.0f)

---

Je rencontre ce type de problème, et à part caster mes arguments en un type unique, je n'ai pas trop de solution (je pourrais bien faire un constructeur qui prend 4 arguments de 4 types différents en template mais je trouve ça moche)

Citation:

---

Envoyé par Spidyy

J'ai trouvé une autre solution :

Je déclare deux classe, une Coloruc avec un constructeur Coloruc (unsigned char r, unsigned char g, unsigned char b, unsigned char a), ma classe Color avec un constructeur Color(const Coloruc & color) et son constructeur en float, et avec la conversion implicit, il accept que je fasse Color red(255, 0, 0).

Ca impose une construction supplémentaire, mais ça marche.

---

Salut

il y a les named constructors :

Code:

---

1 2 3 4

public : static Color Color::Coloruc(unsigned char red, unsigned char green, unsigned char blue, unsigned char alpha = 255); static Color Color::Colorf(float red, float green, float blue, float alpha = 1.f);

---

pour garder une seule classe Color

Citation:

---

Envoyé par dragonjoker59

Dans le même esprit, que se passe-t-il si on appelle ce constructeur boosté avec des arguments de type différent ?

Code:

---

Color( 1.0, 1.0, 1, 1.0f)

---

Je rencontre ce type de problème, et à part caster mes arguments en un type unique, je n'ai pas trop de solution (je pourrais bien faire un constructeur qui prend 4 arguments de 4 types différents en template mais je trouve ça moche)

---

C'est pourtant la bonne solution:

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

#include <boost/utility/enable_if.hpp>   struct Color { template<class T> Color( T const& r, T const& g, T const& b, T const& alpha = T(255), typename boost::enable_if< boost::is_integral<T> >::type* = 0 ) { std::cout << "char\n"; }   template<class T1,class T2,class T3,class T4> Color( T1 const& r, T2 const& g, T3 const& b, T4 const& alpha = T4(1.f) , typename boost:: enable_if_c< boost::is_floating_point<T1>::value || boost::is_floating_point<T2>::value || boost::is_floating_point<T3>::value || boost::is_floating_point<T4>::value >::type* = 0 ) { std::cout << "float\n"; } };   int main() { Color c(1,2,3,4); Color f(1.f,2.f,3.f,0.f); Color fc(1.f,2,3.f,0.f); Color cf(1,2,3,0.f);   }

---

Sortie:

Citation:

---

char
float
float
float

---

Citation:

---

Envoyé par Joel F

Et va falloir arreter avec cette phobie de boost.

---

Si vraiment ça vous donne des boutons, essayez C++0x :mouarf:

Code:

---

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

#include <type_traits> struct Color { template<class T> Color( T , T , T , T = T(255), typename std::enable_if< std::is_integral<T>::value >::type* = 0 ) { }   template<class T> Color( T , T , T , T = T(1.f), typename std::enable_if< std::is_floating_point<T>::value >::type* = 0 ) { } };

---

Ceci étant dit, l'approche générique fait perdre la coercition qui peut être parfois utile (voire voulue) : Color c(300,-1,0); ne génère plus de warning par exemple.

Ca peut être encore plus gênant avec la question de dragonjoker59 relative aux arguments différents. Avec un type entier, les préconditions vont être [0;255], avec un type réel, elles vont être de [0;1]. La définition du contrat devient plus laborieuse (mais en contre partie tire probablement l'avantage de plus de généricité).

Au final, il n'y a plus qu'un seul constructeur qui doit alors probablement passer par une phase de normalisation des arguments. Il devient plus difficile de dire si Color c(1., 25, 0.5) est voulu ou s'il s'agit d'une erreur de frappe pour Color c(1., 2.5, 0.5)

Bref, cette approche générique m'embête. Si elle peut être séduisante par certains points (renforcement du typage de chaque argument + 'abstraction/conceptualisation' de l'interface supérieure), je crains qu'elle ne finisse par être génératrice d'erreurs dans du code lambda.

Finalement, je ne sais encore quelle solution j'adopterais dans un tel cas :
=> utiliser une seule signature à 3/4 arguments et l'autre avec une conversion explicite :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

struct Color { Color( unsigned char , unsigned char , unsigned char , unsigned char = unsigned char(255)) { }     struct RGB { RGB(float,float,float,float = 1.f){} }; Color( RGB) { } };   int main() { Color c(30,1,43); Color c2(Color::RGB(1.f,1.f,1.f)); return 1; }

---

=> utiliser l'idiom du named constructeur comme proposé par kessoufi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

struct Color { private: Color( unsigned char , unsigned char , unsigned char , unsigned char = unsigned char(255)) { } Color(float, float,float,float=1.) { } public: static Color create_rgb(unsigned char a, unsigned char b,unsigned char c,unsigned char d=255) {return Color(a,b,c,d);} static Color create_hsv(float a, float b,float c,float d=1.) {return Color(a,b,c,d);} };   int main() { Color c = Color::create_rgb(30,1,43); Color c2 = Color::create_hsv(1.,1.,1.); return 1; }

---

Ou utiliser la coercition que sur les types integer et la surcharge pour les types flottants :

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

struct Color { public: Color( int , int , int , int = int(255)) { } Color(float, float,float,float=1.) { } Color(double, double,double,double=1.) { } public: Color(long double, long double,long double,long double=1.) { } public: };   int main() { Color c(30,1,43); Color c2(1.,1.,1.); Color c3(1.f,1.f,1.f); return 1; }

---

En écrivant ces lignes, j'ai tendance à pencher pour la première solution (avec RGB explicite).

Une autre manière de résoudre l'ambiguïté est de passer des constantes char, et non des constantes int, à un constructeur prenant des char :

Code:

---

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

struct bar { bar(float,float,float,float) { cout << "float\n"; } bar( char, char, char,char ) { cout << "uchar\n"; } };   int main() { bar b('\1','\2','\16','\4'); bar c(1.f,2.f,3.f,0.f);   }

---

Citation:

---

uchar
float

---

A ce moment, je prefererais utilsier des Strong typedef pour me definir un ColorValue entier et avoir un ctor avec float et un avec ColorValue

Citation:

---

Envoyé par 3DArchi

Si vraiment ça vous donne des boutons, essayez C++0x :mouarf:

---

Jusqu'au bout alors ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <type_traits> struct Color { template<class T , class Enable = typename std::enable_if< std::is_integral<T>::value >::type > Color( T , T , T , T = T(255) ) { }   template<class T , class Enable = typename std::enable_if< std::is_floating_point<T>::value >::type > Color( T , T , T , T = T(1.f) ) { } };

---

il n'y aurait pas plus simple (enfin ne pas sortir l'artillerie lourde pour peut être pas grand chose) ? genre ça :

Color red( (unsigned char) 255, (unsigned char) 0, (unsigned char) 0)

parce que bon dans Color red(255, 0, 0), les arguments ne sont ni des float ni des unsigned char, et ça ne demande qu'un peu de rigueur dans le code.