Inclusion de code source dans différents fichiers d'une bibliothèque en compilation. (Comment faire ?)

Version imprimable

Voir 40 message(s) de cette discussion en une page

Moi non plus je ne vois rien de suspect avec la macro et je ne comprends pas pourquoi ça crash :

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 "serialization.h"
#define REGISTER_KEY(KEY, TYPE, TYPES...)  \
struct KEY : public  odfaeg::Serializer<TYPE, TYPES> { \
    public : \
    KEY () : odfaeg::Serializer<TYPE, TYPES>() {std::cout<<__LINE__<<std::endl;} \
    void register_object (TYPE* object) { \
        setObject(object); \
    } \
    TYPE* allocate_object(int index) { \
        return sallocate(index); \
    } \
    int getTypeIndex () { \
        return odfaeg::Serializer<TYPE, TYPES>::getIndex(); \
    } \
    template <typename Archive> \
    void serialize_object (Archive & ar, int) { \
        odfaeg::Serializer<TYPE, TYPES>::serialize(ar); \
    } \
}; \
public : \
KEY key; \
typedef KEY KEYTYPE; \
static TYPE* allocate (int index) { \
    static KEY aKey; \
    return aKey.allocate_object(index); \
}

J'ai bien fait un ifndef pour éviter de redéfinir la macro si je la défini dans le main.

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
 
#ifndef ODFAEG_BOUNDING_VOLUME_HPP
#define ODFAEG_BOUNDING_VOLUME_HPP
#include "../Math/vec4.h"
#include <string>
#include "../Core/serialization.cpp"
#ifndef BVKEY
#define BVKEY REGISTER_KEY(BVKEY, odfaeg::BoundingVolume, odfaeg::BoundingBox)
#endif
/**
  *\namespace odfaeg
  * the namespace of the Opensource Development Framework Adapted for Every Games.
  */
namespace odfaeg {
/**
  * \file boundingVolume.h
  * \class BoudingVolume
  * \brief Manage a bounding volume for collision detection
  * \author Duroisin.L
  * \version 1.0
  * \date 1/02/2014
  *
  * Base class of all bouding volumes of the framework used for collision detection.
  *
  */
class BoundingVolume;
class BoundingBox;
class BoundingSphere;
class BoundingPolyhedron;
class BaseInterface {
     public :
     void addChild(BoundingVolume* bv) {
        children.push_back(bv);
     }
     std::vector<BoundingVolume*> getChildren() {
        return children;
     }
     std::vector<BoundingVolume*> children;
};
template <typename T>
class Interface : public BaseInterface  {
    public :
        T /* const */ & data() /* const*/{return t_;}
    protected:
        Interface(T & t) : t_(t){
 
        }
        /*const Interface<T>& operator= (const Interface<T>& other) {
            t_ = other.t_;
            return *this;
        }*/
        virtual  ~Interface(){}
    private:
        T & t_;
};
class BoundingVolume : public BaseInterface {
public :
 
    bool intersects(BaseInterface& other) {
        //if(static_cast<C&>(other)) {
            if (children.size() == 0 && other.children.size() == 0) {
                return onIntersects(static_cast<BoundingVolume&>(other));
            }  else if (children.size() == 0 && other.children.size() != 0) {
                  for (unsigned int i = 0; i < other.children.size(); i++) {
                      if (onIntersects(*static_cast<BoundingVolume&>(other).children[i]))
                            return true;
                  }
            } else {
                for (unsigned int i = 0; i < children.size(); i++) {
                    if (other.children.size() == 0) {
                        if (children[i]->onIntersects(static_cast<BoundingVolume&>(other)))
                                return true;
 
                    } else {
                        for (unsigned j = 0; j < other.children.size(); j++) {
                             if (children[i]->onIntersects(*static_cast<BoundingVolume&>(other).children[j]))
                                    return true;
                        }
                    }
                }
            }
        //}
        return false;
    }
    virtual bool onIntersects(BoundingVolume& other) {
    }
    template <typename T>
    bool intersects(Interface<T>* interface) {
        return interface->data().intersects(*this);
    }
    virtual Vec3f getPosition() {
        return Vec3f(0, 0, 0);
    }
    virtual Vec3f getSize() {
        return Vec3f(0, 0, 0);
    }
    virtual Vec3f getCenter() {
        return Vec3f(0, 0, 0);
    }
    virtual void move (Vec3f t) {
    }
    virtual BoundingVolume* clone () {
        return new BoundingVolume(*this);
    }
    const BoundingVolume& operator= (const BoundingVolume& other) {
        return *this;
    }
    template <typename Archive>
    void serialize(Archive & ar) {
        std::cout<<"Serialize bounding volume"<<std::endl;
    }
    void foo() {}
    virtual ~BoundingVolume() {}
    BVKEY
};
}
#endif // BOUNDING_AREAS

Bref j'ai mis des __LINE__ partout et ça crash à la ligne 35 :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
#define BVKEY REGISTER_KEY(BVKEY, odfaeg::BoundingVolume, odfaeg::BoundingBox, odfaeg::BoundingSphere)
#include "odfaeg/Graphics/renderWindow.h"
#include "odfaeg/Graphics/2D/tile.h"
int main(int argc, char* args[]) {
    std::cout<<__LINE__<<std::endl;
    sf::VideoMode mode(800, 600);
    std::cout<<__LINE__<<std::endl;
    sf::ContextSettings settings(0, 0, 4, 3, 0);
    std::cout<<__LINE__<<std::endl;
    odfaeg::RenderWindow window(mode, "test", sf::Style::Default, settings);
    std::cout<<__LINE__<<std::endl;
    odfaeg::Texture tex;
    std::cout<<__LINE__<<std::endl;
    tex.loadFromFile("tilesets/herbe.png");
    std::cout<<__LINE__<<std::endl;
    odfaeg::g2d::Entity* tile = new odfaeg::g2d::Tile (&tex, odfaeg::Vec3f(0, 0, 0), odfaeg::Vec3f(100, 50, 0), sf::IntRect(0, 0, 100, 50));
    std::cout<<__LINE__<<std::endl;
    while (window.isOpen()) {
        std::cout<<__LINE__<<std::endl;
        sf::Event event;
        std::cout<<__LINE__<<std::endl;
        while(window.pollEvent(event)) {
            std::cout<<__LINE__<<std::endl;
            if (event.type == sf::Event::Closed) {
               std::cout<<__LINE__<<std::endl;
               window.close();
               std::cout<<__LINE__<<std::endl;
            }
            std::cout<<__LINE__<<std::endl;
        }
        std::cout<<__LINE__<<std::endl;
        window.clear();
        std::cout<<__LINE__<<std::endl;
        window.draw(*tile);
        std::cout<<__LINE__<<std::endl;
        window.display();
        std::cout<<__LINE__<<std::endl;
 
    }
    delete tile;
    return 0;
}

Et donc au moment du draw, je ne comprend pas pourquoi ça crash là mais quand je ne redéfini pas la macro dans le main, ça ne crash pas, donc le problème vient sûrement de la macro mais je ne vois pas ou.

21/08/2014, 14h05
Invité
J'ai aussi un problème bizarre lorsque j'écris mes données dans le fichier, je me retrouve en effet avec des valeurs non initialisée, et ceci, uniquement lorsque je redéfini la macro :

Voici ce que ça me donne sans redéfinir la macro :
Code:

1 2 0 0 0 0 0 100 100 100 50 50 50 1
Et voici ce que ça me donne en redéfinissant la macro :
Code:

1 2 0 0 0 100 100 100 1112014848 1112014848 50 1 0 0
J'ai deux valeurs bizarre, deux fois la même c'est à dire la valeur 1112014848 qui viennent se rajouter.

Il m'appelle aussi deux fois la méthode serialize dans ma classe de base hors que je ne l'appelle que une fois, bref, on dirait que la macro est redéfinie deux fois quand même donc ce qui me ferait deux objets nommé key dans la classe BoundingVolume ce qui expliquerait sans doute le crash....

Bref je ne comprends pas pourquoi il redéfini ma macro hors que j'ai fais un ifndef.
21/08/2014, 14h21
Invité

Bon en fait j'ai trouvé pourquoi on dirait qu'il faut que les macros aient exactement les même arguments pour que ça marche, je pensais que en redéfinissant la macro REGISTER_KEY que ça remplacerais la définition de la macro REGISTER_KEY par la nouvelle définition dans le main. (Mais en fait non ça la remplace pas, ça en crée une nouvelle.

Du coup je vois pas trop comment faire si je veux redéfinir la macro REGISTER_KEY du fichier boundingVolume.h dans le main, si quelqu'un à une solution je suis preneur.
22/08/2014, 16h18
Invité

Finalement, je pense que je vais laisser tomber ça et définir une seule macro dans ma librairie et puis c'est tout!
Je ne pense pas qu'il y ai une solution.

J'ai lu plusieurs articles au sujet des macros, et normalement, lorsque l'on redonne le même symbole pour une macro déjà définie, celle-ci est redéfinie, il n'y a pas de surcharge de macro possible, mais pas avec les macros variadique. (D'après cet article : http://efesx.com/2010/08/31/overloading-macros/)

Contrairement à ce que je pensais : ma macro est surchargée au lieu d'être redéfinie, du coup j'ai deux objets de types différents mais ayant le même nom dans ma classe et un beau crash. (Car BV_KEY reference deux macros :
REGISTER_KEY(BOUNDINGVOLUMEKEY, odfaeg::BoundingVolume, odfaeg::BoundingBox) et REGISTER_KEY(BOUNDINGVOLUMEKEY, odfaeg::BoundingVolume, odfaeg::BoundingBox, odfaeg::BoundingSphere) et non pas une seule!)

Je pense que c'est à cause du paramètre variadique qui surcharge plusieurs macros en fonction du nombre de paramètres.

Mmm...., comment lui dire de ne pas surcharger mais de redéfinir la macro REGISTER_KEY.

Si quelqu'un à une solution je suis preneur. (Mais je ne pense pas que ça soit possible)

Les macros sont un aspect sombre du language c mais dans mon cas, je ne pense pas qu'il y ai moyen de faire autrement.
23/08/2014, 15h43
Invité

Bon bah après réflexion et quelques test j'ai enfin compris!

Ma macro porte le même nom mais est définie dans deux projet différent! (La librairie et le projet qui l'utilise)
C'est pour cela qu'elle est définie deux fois.

Alors ma question est la suivante existe t'il un moyen d'exporter la définition de la macro en dehors de la librairie ? (Ou bien dans l'autre sens c'est à dire du main vers la librairie)
Afin qu'il ne me les considère plus comme deux macro différente!

(J'ai cherché mais à priori c'est impossible, une fois que le projet est compilé et que la macro est définie, on ne peux plus changer sa définition. :/)
24/08/2014, 10h05
LittleWhite

Citation:

Envoyé par Lolilolight

Alors ma question est la suivante existe t'il un moyen d'exporter la définition de la macro en dehors de la librairie ? (Ou bien dans l'autre sens c'est à dire du main vers la librairie)

La macro, c'est un ordre du préprocesseur. Si la macro est défini dans le main, cela veut dire que à chaque changement du main, la bibliothèque devrait être recompilée afin de refaire la passe du préprocesseur. Cela a peu de sens à vrai dire :?
La bibliothèque, n'est pas sensée bougée. Ou alors, il faut changer le comportement de la bibliothèque, en appelant une fonction précise, une sorte de changement d'état (ou un système de callback, sinon).
24/08/2014, 11h34
Ehonn

Citation:

Envoyé par LittleWhite

La macro, c'est un ordre du préprocesseur. Si la macro est défini dans le main, cela veut dire que à chaque changement du main, la bibliothèque devrait être recompilée afin de refaire la passe du préprocesseur. Cela a peu de sens à vrai dire :?

Sauf si la macro est définie (dans le programme) avant les #include de la bibliothèque, et que celle-ci utilise la macro uniquement dans les fichiers d'entête.
Mais, de base, je déconseille aussi l'utilisation d'une telle macro.

On doit pouvoir tester l'existence d'une macro ou pas avec #ifdef, #ifndef et la définir ou redéfinir (#undef, #define) si besoin est.
24/08/2014, 13h01
Invité

Re :

La macro fait deux choses :

Elle déclare une classe qui hérite d'une classe qui possède un template variadique avec les types que je lui passe en paramètre. (Etant donné qu'elle doit déclarer une classe et que je ne peux pas déclarer une classe dans une fonction, je ne peux pas utiliser de fonction callback.)

Elle déclare aussi un objet de cette nouvelle classe et inclus tout ça dans le .h d'une autre classe, et cet objet est utilisé par une autre classe.

Mais comme j'utilise l'objet déclaré par la macro dans des fichier.cpp, ça ne semble pas marché, de plus le préprocesseur est appliqué deux fois (une fois à la compilation de la librairie, et une autre fois à la compilation du projet utilisant la librairie)

Je sais que le code source de la librairie ne devrait pas être modifié (logiquement) mais dans mon cas j'ai vraiment besoin de le modifier, je n'ai pas trouvé d'autres solutions afin de la rendre plus "personnalisable" avec les nouvelles fonctionnalités du standard c++11/c++14.

La seule solution que j'ai trouvé pour n'appliquer que une fois le préprocesseur est de rendre la librairie header only mais je vais devoir m'arranger pour qu'elle se compile vite.
24/08/2014, 13h48
Bousk

Citation:

Envoyé par Ehonn

Sauf si la macro est définie (dans le programme) avant les #include de la bibliothèque, et que celle-ci utilise la macro uniquement dans les fichiers d'entête.
Mais, de base, je déconseille aussi l'utilisation d'une telle macro.

Ce qui est le plus mauvais choix possible et à ne jamais faire !

Une macro qui définit une classe dans une lib n'a rien d'extraordinaire. Ce qui importe c'est qu'en tant qu'utilisateur de cette lib j'ai un simple include d'un fichier de lib à faire pour utiliser ma class.
24/08/2014, 15h19
Invité

Oui mais c'est la lib qui utilise myclass, pas l'utilisateur. :/

Je veux que la lib utilise myclass que l'utilisateur défini avec une macro. (Avant l'include de la lib par exemple)
24/08/2014, 16h44
ternel

Mais pourquoi voudrait-il faire ca?

Tu ne fais pas #define vector je ne sais pas quoi avant d'inclure <vector>…
24/08/2014, 17h38
Invité

Ma classe possède un template variadique et je veux que l'utilisateur puisse spécifier lui même les types pour le template variadique lors de l'inclusion de la classe à l'aide d'une macro.

Je voudrais donc régénérer le fichier.h (redéclarer la classe donc) avant de l'inclure avec un nombre de paramètres template différent.

J'ai trouvé un lien qui explique un peu ce que je veux faire, c'est une sorte de "reverse engineering" :

http://www.sparxsystems.com/enterpri...agemacros.html

Je veux en fait pouvoir régénérer la macro dans le code.

Le problème ici c'est qu'il garde toujours le code généré par la macro lors de la compilation de la bibliothèque. (Donc ça me fait, un beau crash)
25/08/2014, 09h43
Invité

Ne cherchez plus!

Je pense que je vais simplement modifier le code source de la bibliothèque et la recompiler au cas ou je déciderai de rajouter une classe dérivée pour une classe de base qui se trouve dans la bibliothèque, cela me semble impossible de régénéré du code dans la bibliothèque lors de son utilisation (enfin si, c'est possible, mais ça crash), de plus, dans mon cas, je devrai également rajouter une méthode intersects, dans chaque classe dérivée de la bibliothèque dans mon cas. (c'est à dire une méthode intersects (NewBoundingVolumeType& t))

Encore une fois je pense que c'est faisable avec une macro, mais, à condition de recompiler le code ou de rendre la bibliothèque header only en perdant les avantages de celle-ci c'est à dire moins de temps de compilation.

C'est quand même une grosse librairie et j'ai peur qu'elle mette trop de temps à compiler, elle met déjà plusieurs minutes à se compiler là, si je dois la recompiler à chaque fois avec le projet utilisant la lib je pense que c'est mort. :/
25/08/2014, 10h03
ternel

Je suis curieux de ton projet.
Peux-tu partager le code de ta bibliothèque? ou une partie?

Ça me plairait de travailler dessus sur mon temps libre, si tu le veux bien.
25/08/2014, 11h57
Invité

Salut.

Citation:

Je suis curieux de ton projet.
Peux-tu partager le code de ta bibliothèque? ou une partie?
Ça me plairait de travailler dessus sur mon temps libre, si tu le veux bien.

Oui bien sûr.

Le code source du projet est accessible via mon répertoire git-hub : https://github.com/Lolilolight/ODFAE...ter/src/odfaeg

Il y a trois projets actuel pour tester mon framework : le client, le serveur et un projet non réseau.

Je passe ce sujet en résolu vu que il n'y a pas de solution à ce problème. (A moins de faire une macro qui permet d'ajouter des surcharges de méthodes dans une classe mais ça me semble impossible à faire.)
25/08/2014, 12h14
ternel

Merci beaucoup!

Même si je sens que ma dette de sommeil va s'alourdir prochainement :aie:
25/08/2014, 12h17
Invité

La mienne aussi. (Et c'est déjà le cas)
Il suffit de voir l'ampleur du projet pour comprendre. ^^

Voir 40 message(s) de cette discussion en une page