Discussion :

[NoIdea]

Bonjour à tous,

J'utilise boost 1.57 pour tester l'existence d'un opérateur << avec mingw 4.7 et je remarque un comportement plutôt perturbant avec le code ci-dessous.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <boost/type_traits/has_operator.hpp>
#include <ostream>
#include <iostream>
 
#define BUG
 
class Test
{
 
};
 
#ifdef BUG
bool debBoost = boost::has_left_shift<std::ostream&, const Test&, std::ostream&>::value;
#endif
 
std::ostream& operator<<(std::ostream&, const Test&);
 
bool endBoost = boost::has_left_shift<std::ostream&,const Test&, std::ostream&>::value;
 
int main()
{
    #ifdef BUG
    std::cout<<"debBoost = "<<debBoost<<"\n";
    #endif
    std::cout<<"endBoost = "<<endBoost<<"\n";
}

Globalement, si j'active BUG, debBoost = endBoost = 0, sinon, endBoost =1. Est-ce un comportement normal ?

Ensuite, j'ai voulu tester une solution maison (juste pour ce cas). La voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <ostream>
#include <iostream>
#include <type_traits>
 
class Test
{
 
};
 
struct delay
{
    template<typename T>
    delay(const T&);
};
 
std::false_type operator<<(std::ostream&, delay);
 
bool deb = !std::is_same<decltype(std::declval<std::ostream&>() << std::declval<const Test&>()), std::false_type>::value;
 
std::ostream& operator<<(std::ostream&, const Test&);
 
bool end = !std::is_same<decltype(std::declval<std::ostream&>() << std::declval<const Test&>()), std::false_type>::value;
 
int main()
{
    std::cout<<"deb = "<<deb<<"\n";
    std::cout<<"end = "<<end<<"\n";
}

Et je n'ai pas eu de soucis...

Ce problème est-il uniquement chez moi ?

Finalement, après un troisième test, le problème ne vient pas de boost puisque j'obtiens les même résultats que boost.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
31
32
33
34
35
36
37
38
39
#include <ostream>
#include <iostream>
#include <type_traits>
 
#define BUG
class Test
{
 
};
 
struct delay
{
    template<typename T>
    delay(const T&);
};
 
std::false_type operator<<(std::ostream&, delay);
 
template<typename T>
struct Has
{
    static constexpr bool value = !std::is_same<decltype(std::declval<std::ostream&>() << std::declval<const T&>()), std::false_type>::value;
};
 
#ifdef BUG
bool deb = Has<Test>::value;
#endif
 
std::ostream& operator<<(std::ostream&, const Test&);
 
bool end = Has<Test>::value;
 
int main()
{
    #ifdef BUG
    std::cout<<"deb = "<<deb<<"\n";
    #endif
    std::cout<<"end = "<<end<<"\n";
}

Je suppose que tout ce ci est normal... Est-il possible de faire pour que la valeur soit évaluée lorsqu'elle est demandée et non à la première demande ?



[EDIT] Je n'ai testé le deuxième code qu'après avoir commencé à éditer le message, et je ne pensais pas que le problème venait de boost (je pensais que ma solution allait échouer elle aussi). Quelqu'un pourrait-il déplacer la conversation dans le forum dédié à boost ?

[EDIT2] Finalement, ce n'est pas lié à boost

[ternel]

a priori, c'est parce que tu instancies une template, puis la réinvoque.

à la première instance, il trouve faux, du coup, à la seconde invocation, c'est toujours faux.
Même si entre temps, la cause du faux a changé.

[NoIdea]

a priori, c'est parce que tu instancies une template, puis la réinvoque.

à la première instance, il trouve faux, du coup, à la seconde invocation, c'est toujours faux.
Même si entre temps, la cause du faux a changé.

Oui, c'est ce que j'avais déduis du troisième test... Mais peut-on l'éviter ? Est-ce un comportement lié au compilateur utilisé ?

[ternel]

C'est lié à la nature même des templates.
Une instance précise d'une template est matérialisée à sa première invocation.
Concrètement, le code correspondant est "écrit et compilé" à ce moment-là.

Une seconde invocation se contentera d'utiliser le même code.

[NoIdea]

Ok, mais est-ce garanti que les résultats soient les mêmes avec tous les compilateurs ?

Notamment, si je fait un #define HAS_SHIFT_LEFT(C) !std::is-same... (voir deuxième solution), puis-je être certain que la valeur est recalculée à chaque fois ?
Y a t-il une solution plus "propre" qu'un #define pour obtenir le même résultat ?

[EDIT] Je vais profiter de ce thread pour demander s'il existe un trick pour contourner les problèmes de templates dans le test d'existence de fonction (j'imagine que non, mais on ne sait jamais...). Imaginons que j'ai template<typename T> auto serialize(const T&) mais que cette fonction ne compile pas pour toutes les classes. Est-il possible de définir un constexpr bool hasSerialize<C> ?

[bretus]

[EDIT] Je vais profiter de ce thread pour demander s'il existe un trick pour contourner les problèmes de templates dans le test d'existence de fonction (j'imagine que non, mais on ne sait jamais...).

J'ai vaguement l'impression que ma crainte face à ton précédent thread se confirme. Tu vas essayer de tout faire contrôler à ton compilateur (y compris ce qu'il contrôle déjà) à coup de template qui ne feront qu'une chose : Complexifier ton code.

Imaginons que j'ai template<typename T> auto serialize(const T&) mais que cette fonction ne compile pas pour toutes les classes

Ben tu laisses le compilateur afficher un message d'erreur... Un utilisateur de ton système pourra toujours faire une adaptation pour que ça deviennent possible sur sa classe.

Tu comptes mettre des genres de "concept" sur chaque erreur de programmation possible quand bien même le compilateur effectue déjà un contrôle?