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?

[NoIdea]

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.

Possible... L'idée, c'est surtout de cacher à l'utilisateur ce qu'il se passe à l’intérieur des fonctions (mais il garde accès à toute la spécification via la documentation).

Pour mieux comprendre ce qu'il se passe, imaginons qu'on écrive quelque chose du genre (pseudo code)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
template<typename T>
struct Serialize
{
  static constexpr bool value = hasBoostSerializeFunction || (hasOperator ostream& << (ostream&, const C&) && hasOperator istream& >> (istream&, C&));
  /*Vérifie que serialize ou (<< et >>) vérifie la partie "dynamique" de serialize ou (<< et >>). 
     Bon en gros, que load(save()) = Identity (quand pas d'exception et ...). 
     Cette fonction ne sert qu'au debug. Et fait un lot d'assert par exemple.
  */
  void check();
 
  auto save(ostream&, const C&);
  C load(istream&);
};

L'idée c'est que save et load vont faire les static_assert(value, "..."); permettant d'éviter des erreurs incompréhensibles à la compilation. Et que check va pouvoir faire les tests nécessaires sur le type C pour que lorsqu'il y a une erreur à l’exécution, on puisse trouver l'erreur.

L'utilisateur est alors protégé par la bibliothèque d'erreurs incompréhensibles (compilation ou exécution) et il n'a pas à rajouter du boilerplate code juste parce qu'il a << et >> au lieu de serialize par exemple.

Honnêtement, si on pouvait avoir sur chaque fonction template un static_assert qui soit réussi et la fonction compile, soit fail et explique pourquoi, ce serait tellement un plus au c++ (en gros un concept quoi...). Aussi, un peu de réflexion pour faire des fonctions comme serialize, operator==, ... automatiques, ce ne serait pas de trop (mais il me semble que c'est prévu).

Aussi, pendant que j'y suis, quelqu'un sait-il pourquoi le mot clé const a été inventé mais on a pas continué sur la voie de la vérification statique en C++ ?

[ternel]

Parce que const est beaucoup plus ancien que les templates, etc.

Il permet justement au compilateur de faire énormément de validation et des quantités astronomiques d'optimisations.