Discussion :

[Laurent Gomila]

Bonjour à tous

Désolé pour le titre imprécis, mais pas facile d'en trouver un pour mon problème.

Je possède une classe abstraite, nommée ici Driver, qui sert d'interface entre le programme et des API spécifiques (chaque dérivée de Driver implémente une API différente).

Pour des raisons diverses et justifiées, je me suis codé une petite classe proxy pour cacher les appels du genre Driver->SetSomeState(true) derrière des affectations du genre Driver->SomeState = true.

Voici un code complet minimal qui reproduit le problème (que j'explique juste après) :

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
class Driver;
Driver* GlobalDriver;
 
class Driver
{
private :
 
    virtual void SetSomeState(bool) {}
 
public :
 
    template <typename T, void (Driver::*Func)(T)>
    struct State
    {
        State& operator =(T Value)
        {
            (GlobalDriver->*Func)(Value);
            return *this;
        }
    };
 
    struct States
    {
        State<bool, &Driver::SetSomeState> SomeState;
    };
 
    States TheStates;
};
 
 
int main()
{
    GlobalDriver = new Driver;
    GlobalDriver->TheStates.SomeState = true;
 
    return 0;
}

Mon problème est que ce code est valide, mais ne compile pas (Visual C++ 8 me sort une internal compiler error, suivie d'un crash du compilateur).

J'ai isolé le problème :

Si les fonctions de Driver ne sont pas virtuelles cela compile, mais je suis obligé de les laisser virtuelles.
Si la classe States est définie en dehors de Driver cela compile, mais je ne peux pas non plus le faire car toutes deux sont dépendantes l'une de l'autre.
Je pourrais également intercaler une fonction non virtuelle entre ma classe State et l'appel à la fonction virtuelle, mais c'est exclu car je dois quoiqu'il arrive être certain qu'en mode release mon mécanisme de proxy ne laisse pas de trace (ie. soit équivalent à l'appel direct).

J'ai trituré le code dans tous les sens, mais sans jamais réussir à le faire compiler tout en gardant des fonctionnalités identiques.

Une idée ??

[Swoög]

avec ton code, avec g++, j'ai :

laurent.cpp: In member function `Driver::State<T, Func>& Driver::State<T, Func>::operator=(T)':
laurent.cpp:17: error: `GlobalA' was not declared in this scope

Code :

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

            (GlobalA->*Func)(Value);

GlobalA correspond à quoi ?

[Laurent Gomila]

Oups, un vieux truc qui trainait. Il fallait lire GlobalDriver.

[Swoög]

Bon, c'est définitif... change de compilateur tout simplement

j'ai testé avec G++ sous nunux et Mingw (Dev-C++) sous Windows, et il n'y a pas de problèmes...

il doit bien y avoir une config sous VC++ pour spécifier le compilo non ?

[Laurent Gomila]

Le problème est que mon code doit supporter Visual C++ (et j'imagine que si le 8 ne passe pas, les autres non plus).

Bon, c'est tout de même rassurant de voir que gcc fait correctement son boulot.

[Foobar1329]

Hello,

Le problème est que mon code doit supporter Visual C++ (et j'imagine que si le 8 ne passe pas, les autres non plus).

Bon, c'est tout de même rassurant de voir que gcc fait correctement son boulot.

Bon, j'ai lu et relu les passages de ma n1905 qui concernent l'opérateur de prise d'adresse, notamment sur les fonctions membres virtuelles, et je n'ai rien vu dedans qui pourrait empêcher de faire ce que tu fais. Le problème du compilo vient peux-être du fait qu'il ne sait pas récupérer &Driver::SetSomeState à l'instanciation du template State<bool, &Driver::SetSomeState> qui est faite quand Driver n'est pas encore complètement défini (à la définition de la structure States) . Mais là, il faut attendre l'avis d'experts du langage our se prononcer en faveur d'un bug MS ou pas, car prise d'adresse de fonction membre virtuelle pendant instanciation de classe template englobée =>

En attendant, j'ai trouvé une solution pour compiler selon tes exigences : j'ai encapsulé la fonction virtuelle, dans une structure qui est complètement définie au moment de l'instanciation du template.

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
40
41
class Driver;
Driver* GlobalDriver;
 
class Driver
{
private :
 
    struct Job{
        virtual void SetSomeState(bool) {}
        virtual void SetAnotherState(bool) {}
    } jopic;
 
public :
 
    template <typename T, void (Driver::Job::*Func)(T)>
    struct State
    {
        State& operator =(T Value)
        {
            (GlobalDriver->jopic.*Func)(Value);
            return *this;
        }
    };
 
    struct States
    {
        State<bool, &Driver::Job::SetSomeState> SomeState;
        State<bool, &Driver::Job::SetAnotherState> AnotherState;
    };
 
    States TheStates;
};
 
 
int main()
{
    GlobalDriver = new Driver;
    GlobalDriver->TheStates.SomeState = true;
    GlobalDriver->TheStates.AnotherState = false;
    return 0;
}

A+

[Laurent Gomila]

Intéressant. Par contre c'est assez ugly, parce que du coup les drivers doivent hériter de Driver::Job, et par conséquent je dois y mettre toutes les fonctions à redéfinir, même celles qui ne concernent pas les états. En fait à terme c'est également impossible (niveau design de classes).

Mais au moins ça met bien en évidence une autre des causes de l'erreur (classe pas entièrement définie). Et effectivement il serait intéressant de savoir si tout cela est bien défini par la norme, ou si je m'aventure dans un quelconque comportement aléatoire.

[Jean-Marc.Bourguet]

Et effectivement il serait intéressant de savoir si tout cela est bien défini par la norme, ou si je m'aventure dans un quelconque comportement aléatoire.

Une erreur interne est toujours un probleme du compilateur. Reporte le a MS.

Et dans ce cas-ci, j'ai pas l'impression que c'est suite a une erreur dans le code, en tout cas tout me semble correct (ca passe avec ma collection de version de g++ et avec Sun CC).

Des pistes -- je ne connais pas VC++ du tout -- pour essayer de contourner le probleme:
- si j'ai bien compris, il y a different modes de gestion des pointeurs vers membres: essaie de jouer avec (en particulier le mettre sur la maniere la plus conforme)
- essaie d'introduire une classe de base de Driver et qui servirait pour le deuxieme parametre de State
- essaie d'ajouter un troisieme paramatre a State

Code :

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

1
2
    template <typename T, typename U, void (U::*Func)(T)>
    struct State {...}

[Laurent Gomila]

- si j'ai bien compris, il y a different modes de gestion des pointeurs vers membres: essaie de jouer avec (en particulier le mettre sur la maniere la plus conforme)

Je n'ai rien trouvé de tel dans les options du compilo. Tu aurais des précisions sur cette info ?

- essaie d'ajouter un troisieme paramatre a State

Pas mieux.

- essaie d'introduire une classe de base de Driver et qui servirait pour le deuxieme parametre de State

Ca règle le problème, en effet. Au final ça me donne un code assez alambiqué pour finalement pas grand chose, mais bon il faut ce qu'il faut (je me console en regardant comment est codé boost -- c'est blindé de macros anti-bug compilateurs)

Question subsidiaire à deux balles : la fonction membre que je passe en paramètre template est privée, hors cela ne me génère pas d'erreur ; alors qu'un passage de la même fonction en paramètre de fonction génèrerait une erreur de compilation. J'imagine que c'est conforme à la norme, mais ça ne me paraît pas logique.

[Jean-Marc.Bourguet]

Je n'ai rien trouvé de tel dans les options du compilo. Tu aurais des précisions sur cette info ?

D'après ce que j'ai compris -- je n'ai jamais utilisé un compilo de MS sérieusement -- le compilo de MS implémente une heuristique qui joue avec la taille des pointeurs vers membre, mais a une option pour forcer un comportement standard. Mais c'est peut-être plus le cas de VC++8

Question subsidiaire à deux balles : la fonction membre que je passe en paramètre template est privée, hors cela ne me génère pas d'erreur ; alors qu'un passage de la même fonction en paramètre de fonction génèrerait une erreur de compilation.

Je ne vois pas de problème à ce qu'un membre passe un pointeur vers une fonction membre privée.

[Laurent Gomila]

Je ne vois pas de problème à ce qu'un membre passe un pointeur vers une fonction membre privée.

Ok, sortons de cet exemple, en voici un plus explicite :

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
class A
{
    void PrivateFunc() {}
};
 
template <void (A::*Func)()>
struct Test
{
    // F passée en paramètre template de la fonction
    template <void (A::*F)()>
    void F1(A a) {(a.*F)();}
 
    ///  F passée en paramètre de la fonction
    void F2(A a, void (A::*F)()) {(a.*F)();}
 
    ///  F passée en paramètre template de la classe
    void F3(A a) {(a.*Func)();}
};
 
int main()
{
    A a;
    Test<&A::PrivateFunc> t;
 
    t.F1<&A::PrivateFunc>(a); // Erreur
    t.F2(a, &A::PrivateFunc); // Erreur
    t.F3(a);                  // OK
 
    return 0;
}

[Jan Rendek]

Je ne saurais pas te citer le standard à ce sujet, mais je pense que ce n'est pas permis.
D'ailleurs, ni g++, le compilo d'intel ne l'autorise. Les deux refusent d'instancier le template.

[Matthieu Brucher]

Pour la première écriture, avec un t.template F1<...>, ça ne marche pas non plus ?

[Jean-Marc.Bourguet]

Code :

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

    Test<&A::PrivateFunc> t;

Ceci ne devrait pas passer. Cela passe dans ton message initial parce que le type est defini a l'interieur de A.

[Laurent Gomila]

Ceci ne devrait pas passer. Cela passe dans ton message initial parce que le type est defini a l'interieur de A.

Pourtant, une classe imbriquée n'a pas plus de "droit" sur sa classe parent que n'importe quelle autre classe, non ?

De toute façon, le second exemple que je fournit compile également, ce qui veut dire que c'est le compilo qui n'est pas conforme.

[Jean-Marc.Bourguet]

Pourtant, une classe imbriquée n'a pas plus de "droit" sur sa classe parent que n'importe quelle autre classe, non ?

Il me semble que c'est un des changements de 2003. En tout cas ton premier exemple compile avec como et gcc 4.1.1 en le modifiant comme ceci:

Code :

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

1
2
3
4
5
6
        State& operator =(T Value)
        {
            (GlobalDriver->*Func)(Value);
            GlobalDriver->SetSomeState(Value);           
            return *this;
        }

De toute façon, le second exemple que je fournit compile également, ce qui veut dire que c'est le compilo qui n'est pas conforme.

Je ne suis pas le dernier mot en la matiere -- surtout que j'ai pas le temps de verifier aux sources --, mais je ne suis pas le seul de cet avis:

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
Comeau C/C++ 4.3.3 (Aug  6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing.  All rights reserved.
MODE:strict errors C++
 
"ComeauTest.c", line 23: error: function "A::PrivateFunc" is inaccessible
      Test<&A::PrivateFunc> t;
               ^
 
"ComeauTest.c", line 25: error: function "A::PrivateFunc" is inaccessible
      t.F1<&A::PrivateFunc>(a); // Erreur
               ^
 
"ComeauTest.c", line 26: error: function "A::PrivateFunc" is inaccessible
      t.F2(a, &A::PrivateFunc); // Erreur
                  ^
 
3 errors detected in the compilation of "ComeauTest.c".

g++ dit la meme chose (mais formate moins bien pour citer).

[Laurent Gomila]

Ok, merci pour toutes ces infos

[JolyLoic]

Pourtant, une classe imbriquée n'a pas plus de "droit" sur sa classe parent que n'importe quelle autre classe, non ?

En théorie, non. Par contre, j'ai déjà remarqué que c'était le cas sous visual studio 2005.

[Swoög]

Heu, perso il m'a semblé remarquer que les classes imbriquées avaient accès au membres protected et private des classes qui les contiennent (logique dans un sens puisqu'elles font elle-même partie des membres)...

Pour info je travail avec G++

ensuite, peut-être que je me suis trompé...