IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Boost C++ Discussion :

boost::variant, problème de conception ?


Sujet :

Boost C++

  1. #1
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Par défaut boost::variant, problème de conception ?
    Bonsoir à tous,

    Je dispose d'une classe A, qui contient un vecteur d'objets de classe B. Sauf que cette classe B est une classe template utilisée pour envoyer des données à un shader.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    class A
    {
        private:
            std::vector<B<T> > monVecteur; // Problème
    };
    Je connais à l'avance les types avec lesquels la classe B peut-être instanciée : il s'agit en fait de tous les types de données que l'on peut envoyer à la carte graphique.

    Ceci étant dit, boost::variant m'est donc apparue comme la solution idéale et, en fait, fonctionne plutôt bien. Le soucis c'est que je peux envoyer plus de types que la limite me le permet (la constante BOOST_VARIANT_LIMIT_TYPES) : float, int, uint, vec2, vec3, vec4, mat2x2, mat3x3, mat4x4, sampler2D, sampler3D... bref je dépasse la limite).

    Mes questions : il y a t-il un moyen de surmonter la limite (car, en fait, mes types sont vraiment connus à l'avance, et je suis sûr qu'il n'y en aura pas d'autres), ou alors si vous avez une autre idée de design, même si celui que j'ai est très trsèc ommode à utiliser.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    class A
    {
        private:
            std::vector<B <boost::variant<float, int, ...> > > monVecteur; // Génial tant que je dépasse pas la limite
    };
    Mirci !

  2. #2
    Membre Expert
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Par défaut
    Peut être en utilisant un boost.Any?

  3. #3
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Par défaut
    Oui j'y ait pensé, mais la doc de boost::variant indique que boost::any effectue pas mal d'allocations dynamiques... Dans mon cas ce sont des vector que je vais parcourir assez souvent.

  4. #4
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Avec make_variant_over t'as aussi la même limite ?

  5. #5
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Bonjour,
    La solution de loufoque est la démarche préconisée par Boost;
    Cependant, si elle ne fonctionne pas avec ton compilateur, tu peux toujours modifier BOOST_VARIANT_LIMIT_TYPES (variant/variant_fwd.hpp), sachant que cette limite doit rester inférieure à BOOST_PP_LIMIT_REPEAT (256).
    Enfin, si tu es patient, il te faudra attendre une version de Boost C++0x avec les variatic templates

  6. #6
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Par défaut
    Merci à vous deux, exactement ce que je recherchais .

  7. #7
    Rédacteur
    Avatar de Bakura
    Homme Profil pro
    Étudiant
    Inscrit en
    Septembre 2005
    Messages
    1 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2005
    Messages : 1 386
    Par défaut
    Grrr.... il me faut ces variadic templates :'(...

    J'ai changé mon design, je vous expose le problème. Maintenant, j'ai un manager qui permet d'enregistrer des fonctions appelées "fonction sémantique" (c'est le choix du papier concernant le nom...). Ces fonctions renvoient un objet de type T, qui peut-être soit un float, soit une matrice, soit un vecteur... En gros, tout ce qu'on peut "envoyer" à un shader (et même si je connais A L'AVANCE tout ce qu'on peut lui passer, je trouve ça chiant d'avoir un long boost::variant, surtout qeu si jamais le langage de shader vient à accepter de nouveau type, ben il faut que j'ajoute à la main les types, pas pratique)...

    Donc, cette classe est un singleton (j'aurais pu mettre des fonctions statiques et un map statique, mais je toruve le singleton plus propre, non ?), et j'enregistre certaines variables prédéfinies, par exemple, dans ma classe Camera, j'ai une fonction qui renvoit une certaine matrice. Je peux faire ainsi quelque chose comme ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    semanticManager.RegisterFunction (Camera::MaFonctionQuiRetourneMatrice);
    Ce qui est bien, c'est que ces fonctions ne prennent jamais de paramètre, retournent juste valeur, donc je peux facilement jouer de std::tr1::function.

    Voici le code :

    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 KnSemanticFunctionManager
    /// \brief Classe stockant les fonctions sémantiques utilisées pour les liens dynamiques des shaders. Les fonctions doivent être
    /// enregistrées au préalables (certaines le sont automatiquement)
    class KnSemanticFunctionManager : public KnSingleton<KnSemanticFunctionManager>
    {
    	friend class KnSingleton<KnSemanticFunctionManager>;
     
    	typedef std::tr1::function<const FUCK JE VEUX DES TYPES & ()> SemanticFunction;
     
    	public:		
    		// Retourne la fonction sémantique
    		void GetSemanticFunction
     
    		// Ajoute une fonction sémantique
    		void RegisterSemanticFunction (const std::string & name_, const SemanticFunction semanticFunction_);
     
    		// Supprime une fonction sémantique
    		void RemoveSemanticFunction (const std::string & name_);
     
    	private:
    		// Constructeur
    		KnSemanticFunctionManager ();
     
    		// Destructeur
    		~KnSemanticFunctionManager ();
     
    	private:
    		///< Tableau associatif associant la fonction sémantique à son nom
    		std::map<std::string, SemanticFunction> semanticFunctions;
    };
    Je pense que le mieux est encore d'utiliser boost::any, après tout... Qu'en pensez-vous ? Voyez vous d'autres soltuions (pour moi c'est la plus propre...). En gros, en fonctionnement, c'est très pratique, car lorsque je vais chargé mon shader, j'aurais certaines variables prédéfinies (par exemple "ModelViewMatrix"), cette fonction étant déjà enregistrée, je n'aurai qu'à la récupérer dans le manager, et tout ce fera automatiquement. Lorsque je devrai envoyer la variable au shader, je n'aurai qu'à appeler la fonction correspondante qui renverra une matrice, et hop ^^.

    Au passage, quelle est le moyen optimal d'envoyer des objets std::tr1::function à une fonction ? Par référence on par valeur ? Et quid de la fonction GetSemanticFunction ? Faut-il renvoyer la fonction par référence ?

    Merci

Discussions similaires

  1. Problème de conception avec les mutex de Boost
    Par Benoit_T dans le forum Threads & Processus
    Réponses: 1
    Dernier message: 22/03/2012, 17h15
  2. [VB6][UserControl et OCX]Problème de conception
    Par jacma dans le forum VB 6 et antérieur
    Réponses: 8
    Dernier message: 19/01/2006, 22h37
  3. Petit problème de conception sur access
    Par coooookinette dans le forum Modélisation
    Réponses: 3
    Dernier message: 18/12/2005, 18h24
  4. Gestion des départements problème de conception
    Par snoopy69 dans le forum Modélisation
    Réponses: 7
    Dernier message: 11/10/2005, 13h08
  5. Problème de conceptions de tables
    Par dtavan dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 23/05/2004, 23h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo