Templates et traits, constructeur de conversion

Version imprimable

Bonjour à tous,

Je dispose d'une classe de string template (composée d'un std::basic_string<T>), que j'ai jusqu'alors utilisée comme std::string, c'est à dire avec T = char (on va l'appeler str).
Cependant, j'ai récemment eu besoin d'utiliser des string unicode, donc T = unsigned int (on va l'appeler ustr).

Pour l'instant (je simplifie un peu), je n'ai qu'un constructeur :
Code:

1 2 3 4 5 6 7 8 9 template<class T> class str_t { public : str_t(const T* array); // ... };
Du coup, si je peux écrire ceci :

Code:

str s = "ma string";

... ceci n'est pas possible :

Code:

ustr s = "ma string";

... car "ma string" est un tableau de char, pas un tableau de uint.
Il me faudrait écrire :

Code:

ustr s = UTF8ToUnicode("ma string");

J'aimerai pouvoir ajouter un constructeur à ma classe ustr pour qu'elle soit capable de faire la conversion implicitement.

Pour cela, je pourrais faire un copier coller de la classe str_t et la spécialiser pour T = uint, mais c'est sacrément moche (str_t est une classe assez énorme)...

Du coup j'ai eu une idée qui fait intervenir les traits :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 template<class T> class str_t { private : std::basic_string<T> s; public : str_t(const T* array) { s = array; } str_t(const char* array) { s = StringTraits<T>::Convert(array); } };
Problème si T = char : il y a conflit entre les deux constructeurs.
Je me suis donc dit que, si le compilateur (gcc) ne pouvait pas compiler le second constructeur (qui est de toute manière inutile pour T = char), alors il "l'oublierait" et se contenterai du premier.

J'ai donc écrit StringTraits de la sorte :
Code:

1 2 3 4 5 template<class T> class StringTraits { // Rien, pour provoquer une erreur de compilation. };
... et sa spécialisations :
Code:

1 2 3 4 5 6 template<> class StringTraits<uint> { public : std::basic_string<uint> Convert(std::string s); };
A ma grande surprise, le compilateur n'essaye même pas de compiler le second constructeur, et indique toujours qu'il y a un conflit...

Avez-vous une idée de comment je pourrais m'en sortir ?

Bon eh bien j'ai trouvé un moyen de contourner le problème :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template<class T>
class str_t
{
public :
 
    // On rend le constructeur générique
    template<class N>
    str_t(const N* array)
    {
        s = StringTraits<T>::Convert(array);
    }
 
    // ...
};

Avec :

Code:

1
2
3
4
5
6
7
8
9
10
11
template<class T>
class StringTraits
{
public :
 
    // On implemente seulement la convertion T -> T par défaut
    static std::basic_string<T> Convert(std::basic_string<T> s)
    {
        return s;
    }
};

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
template<> class StringTraits<uint>
{
public :
 
    // Conversion par défaut
    static std::basic_string<uint> Convert(std::basic_string<uint> s)
    {
        return s;
    }
 
    // Conversion avec char
    static std::basic_string<uint> Convert(std::basic_string<char> s)
    {
        return UTF8ToUnicode(s);
    }
};

20/05/2010, 12h57
3DArchi
Salut,
Tu peux quand même conserver ton constructeur avec le type de base et éviter une conversion 'vide'. Le constructeur générique n'est instancié que si un autre n'est pas trouvé avant :
Code:

1 2 3 4 5 6 7 8 9 template<class T> class str_t { public : // sans conversion str_t(const T* array); // avec conversion template<class N> str_t(const N* array)

Je ne savais pas, merci !
Ceci dit, la différence en terme de performance est assez faible non ? Un compilateur pas trop mauvais devrait pouvoir optimiser l'appel à Convert() (ou faut-il que je la déclare inline pour être sûr ?).

Edit :
J'ai un nouveau soucis... Je dispose également d'un type perso pour les pointeurs (qui ne fait rien d'autre que de s'initialiser à NULL, mais c'est déjà pas mal), que je vais appeler ptr. Ce type dispose d'un constructeur implicite vers le type de donnée pointée :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 template<class T> class ptr { T* p; public : ptr() : p(NULL) {} ptr(T* value) : p(value) {} };
Mon problème :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 void f(const str& s) { } void f(ptr<int> p) { } int main(int argN, char** args) { str s = "hello"; int i = 5; ptr<int> p = &i; f(s); // Ok f(p); // Ok f(&i); // Erreur }
L'erreur en question :

Citation:

error: call of overloaded 'f(int*)' is ambiguous
note: candidates are: void f(const str&)
note: void f(ptr<int>)

Ma classe str ne dispose évidemment pas d'un constructeur implicite pour les int*, mais il reste toujours celui-ci :
Code:

1 2 3 4 5 template<class N> str_t(const N& mValue) { s = StringConverter<T>::Construct(mValue); }
... qui ne compile pas si N = int*, mais le compilateur semble s'en ficher complètement... (si je retire ce constructeur, l'ambiguïté dans le main disparait).

J'ai trouvé la parade, avec un genre de boost::enable_if :

Code:

1
2
3
4
5
        template<class N>
        str_t(const N& mValue, typename StringConverter<T>::template IsDefined<N>::Type* mEnableIf = 0)
        {
            sValue_ = StringConverter<T>::Construct(mValue);
        }

Puis :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    template<> class StringConverter<uint>
    {
    public :
 
        template<class N, class Dummy = void>
        struct IsDefined
        {
        };
 
        template<class Dummy> struct IsDefined< str_t<char>, Dummy > { typedef bool Type; };
        template<class Dummy> struct IsDefined< std::string, Dummy > { typedef bool Type; };
        template<class Dummy> struct IsDefined< const char*, Dummy > { typedef bool Type; };
        template<class Dummy> struct IsDefined< char*, Dummy >       { typedef bool Type; };
        template<uint N, class Dummy> struct IsDefined< const char[N], Dummy > { typedef bool Type; };
        template<uint N, class Dummy> struct IsDefined< char[N], Dummy >       { typedef bool Type; };
 
        // ...
    };

La syntaxe est assez horrible, mais c'est totalement transparent pour l'utilisateur, donc ça me va !
Ca aurait d'ailleurs pu résoudre le problème du post original, maintenant que j'y pense :)

Citation:

Envoyé par Kalith

Je ne savais pas, merci !
Ceci dit, la différence en terme de performance est assez faible non ?

Question de lisibilité et ... lire la suite
Citation:
Envoyé par Kalith
Ma classe str ne dispose évidemment pas d'un constructeur implicite pour les int*, mais il reste toujours celui-ci :
Code:

1 2 3 4 5 template<class N> str_t(const N& mValue) { s = StringConverter<T>::Construct(mValue); }
... qui ne compile pas si N = int*, mais le compilateur semble s'en ficher complètement...
Et oui, un constructeur semble exister donc les 2 fonctions sont également possibles. Il est vrai que à partit du moment où tu définis un constructeur template, il y a de grandes chances que ce constructeur puisse être valide dans beaucoup d'expression et que le compilateur la teste pour évaluer l'expression y compris à des endroits où tu ne t'y attends pas. C'est pour ça que tu devrais le déclarer comme explicit ... et ne laisser implicit que celui vers le type d'instanciation de ton générique :
Code:

1 2 3 4 5 6 7 8 9 template<class T> class str_t { public : // sans conversion str_t(const T* array); // avec conversion template<class N> explicit str_t(const N* array)
Par conséquent :
Code:

1 2 3 4 std::string ch1("implicite"); std::wstring ch2(L"explicite"); str_t<char> mes_ch = ch1.c_str(); // implicite str_t<char> mes_ch2 = str_t<char>(ch2.c_str()); // nécessite d'appeler explicitement le constructeur
Je n'ai pas tout regarder ta cuisine sur avec enable_if, mais ça m'a l'air bien compliqué pour quelque chose d'aussi simple qu'une fonction de conversion.

Du coup, je me souvenais avoir déjà fait quelque chose de ce genre, j'ai fouillé un peu et je me suis rendu compte qu'effectivement, j'avais une différence avec toi : ma conversion demande 2 arguments génériques : un source et un destination. Ce que tu as décliné en plusieurs fonctions dans ta structure. Pourquoi pas. Mais le jour où tu introduis un nouveau type tu es obligé de revenir toucher à toutes tes structures existantes pour ajouter ce nouveau type. En travaillant sur le couple (src;dst) l'introduction d'un nouveau type ne nécessite que l'ajout des nouveaux couples de conversion 'à côté' des existants. Pas besoin de modifier le code déjà écrit (open/close principle) :
Code:

1 2 template<class TCharDest, class TCharSource> struct conversion; // puis spécialisation pour conversion<T,T>, conversion<char,wchar_t> et conversion<wchar_t,char>

Citation:
Envoyé par 3DArchi
Par conséquent :
Code:

1 2 3 4 std::string ch1("implicite"); std::wstring ch2(L"explicite"); str_t<char> mes_ch = ch1.c_str(); // implicite str_t<char> mes_ch2 = str_t<char>(ch2.c_str()); // nécessite d'appeler explicitement le constructeur
C'est précisément ce que je voulais éviter, cf. mon premier post.
Je dispose de fonctions libres UTF8ToUnicode() et UnicodeToUTF8() qui pourraient aussi faire l'affaire, mais je voulais que l'utilisation d'un string unicode soit aussi simple que possible, et que je puisse écrire des choses du style :
Code:

1 2 3 4 5 6 7 ustr s = " resultat = truc "; if (s.Find("=")) { s.Trim(' '); vector<ustr> array = s.Cut("="); // ... }
... plutôt que de devoir encombrer inutilement la synthaxe :
Code:

1 2 3 4 5 6 7 ustr s = UTF8ToUnicode(" resultat = truc "); if (s.Find(UTF8ToUnicode("="))) { s.Trim(UTF8ToUnicode(' ')); vector<ustr> array = s.Cut(UTF8ToUnicode("=")); // ... }
... alors que tout string/caractère UTF8 est convertible en Unicode (comme float -> double, c'est une promotion de type).

Citation:

Envoyé par 3DArchi

Je n'ai pas tout regarder ta cuisine sur avec enable_if, mais ça m'a l'air bien compliqué pour quelque chose d'aussi simple qu'une fonction de conversion.

Je suis d'accord, mais il faut voir qu'en réalité je dispose de beaucoup d'autres fonctions de conversions (types numériques, booléen, pointeur, ...).

Je n'ai montré que la surface de mon code ici.
Enfait, ma classe StringConverter dispose de deux types de fonction :

Construct() : appelée par le constructeur template, n'est définie que pour la conversion string -> string.
Convert() : appelée par la fonction membre template str_t::Convert(), l'opérateur +, l'opérateur += et l'opérateur << (tous templates eux aussi), est définie pour tous les types convertible en string.
Citation:
Envoyé par 3DArchi
En travaillant sur le couple (src;dst) l'introduction d'un nouveau type ne nécessite que l'ajout des nouveaux couples de conversion 'à côté' des existants. Pas besoin de modifier le code déjà écrit (open/close principle) :
Code:

1 2 template<class TCharDest, class TCharSource> struct conversion; // puis spécialisation pour conversion<T,T>, conversion<char,wchar_t> et conversion<wchar_t,char>
Effectivement. Je vais voir si je peux faire ça de cette manière, merci.

22/05/2010, 19h21
Kalith

J'ai suivi ton conseil sur la classe de conversion, et ça marche très bien.
J'ai pu rendre d'autres classes plus haut niveau (un vecteur 3d, une classe de couleur, ...) convertible en quelques lignes de code, alors qu'il me fallait auparavant définir plusieurs opérateurs libres.
Merci :)