Discussion :

[nostrora]

Bonjour,

J'ai une question sur l'orienté objet en C++, je souhaiterais crée un objet par rapport à son ID

Par exemple :

J'ai 3 classe fille qui contienne des id qui ne change jamais avec maClass::getId();

Dans le main en gros j'aimerais crée l'objet en fonction du nombre que je lui envoi

J'ai 3 class : id 1 4 et 6

Si j'envoi 1 alors il crée la classe 1
Et j'aimerais faire sa SANS if, ou switch, quelque chose de dynamique donc.

Vous avez une idée vers quoi je pourrais me tourner ?

Merci bien

[Bousk]

Bonjour,

quelle est cette idée saugrenue ? Et ces conditions fantaisistes ?

Si tu as des class class Class1; class Class2; .... alors tu peux t'en tirer avec des macros

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Class1;
class Class2;
#define CREATE_CLASS(id) Class##id
 
int main()
{
 CREATE_CLASS(1) myClass;
 CREATE_CLASS(2)* dynamicClass = new CREATE_CLASS(2);
}

Cependant:
- cette idée est vraiment limite, je ne vois aucune raison sensée et logique à vouloir faire ça. Ceci est sûrement très bien et utilisé dans des langages de scripts comme php ou que sais-je, mais ne l'est pas en C++.
- impossible de faire un CREATE_CLASS avec une variable en paramètre. Du coup c'est quelque chose d'on ne peut plus statique.
- aucune notion d'orienté objet ici. Utiliser des class ne signifie pas orienté objet.

Donc, avec une vraie expression du besoin, et la suppression de tes conditions fantaisistes (exit le "SANS if, ou switch, quelque chose de dynamique donc"), on pourra proposer une vraie solution.

[nostrora]

D'accord

Donc je souhaite faire un protocole réseau avec des messages

J'ai à peu pret 800 messages chaqu'un contenant un ID (1,2,3,4, .... 755,756 etc..)

Quand mon serveur envoie un message, il envoie l'ID et donc j'aimerais crée le message en fonction de l'ID que je reçois

[Bousk]

Un simple switch

[nostrora]

C'est ce que je disait avec ma "condition fantaisiste". Je voudrais une autre méthode qu'un switch de 800 cases

[Emmanuel Deloget]

C'est ce que je disait avec ma "condition fantaisiste". Je voudrais une autre méthode qu'un switch de 800 cases

A mettre au propre (mais le principe est quand même valide). Il ne requiert qu'une seule chose : que tes classes de message dérivent toutes de la même classe mère (pas forcément une mauvaise chose ; à voir si ça correspond à ton design - de toute façon si tu veux utiliser les objets en question, tu as besoin d'en connaître l'interface).

Quelques pistes de mise au propre :
* encapsuler dans un objet
* les makers ne sont plus des fonctions, mais des objets (avec des propriétés comme le nom, ..., histoire d'avoir des infos supplémentaires pour le debug ou le runtime)

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
 
typedef msg_base_class *(*maker_func_type)(const msg_data&)
typedef std::map<unsigned int id, maker_func_type> maker_map_type;
 
maker_map_type maker_map;
 
void add_maker(unsigned int id, maker_func_type func)
{
    // add only if the id is not associated with an existing maker
    make_map_type::iterator_type it = maker_map.find(id);
    if (it == maker_map.end()) {
        maker_map[id] = func;
    } else {
        std::stringstream s; 
        s << "id " << id << " is already bound to a message maker";
        throw std::runtime_error(s.str());
    }
}
 
msg_base_class *make(unsigned int id, const msg_data& data)
{
    make_map_type::iterator_type it = maker_map.find(id);
    if (it != maker_map.end()) {
       return it->second(data);
    }
    return NULL; // or nullptr in C++11
}

[jblecanard]

Hello

quelle est cette idée saugrenue ? Et ces conditions fantaisistes ?

Ce n'est pas si saugrenu, et c'est même un besoin qui peut revenir souvent.

Je vais te montrer une technique pour faire cela nostrora, mais quelques mises en gardes:
- Tu dois avoir une interface commune à toutes tes classes de messages.
- Pèse bien la décision de vouloir implémenter et surtout maintenir 800 classes différentes. 800 ! Il y a peut-être une autre manière de s'y prendre, il faut voir avec des gens qui ont déjà implémenté des protocoles.
- Ma technique se base sur le mécanisme d'initialisation statique. Ca fera tout de même 800 std::string stockées en statique dans ton exécutable/bibliothèque.

Le principe est d'utiliser un singleton qui va servir de factory et dans lequel on va enregistrer nos classes à l'initialisation statique en lui donnant une fonction de construction. Avec un template et en acceptant de laisser les constructeurs des messages en accès public, le seul ajout du ClassID et la dérivation du template suffit à rendre la classe instanciable par son ID.


Voici le code.

[nostrora]

Merci 1000 fois pour ce code. C'est exactement ce que je voulais. Je n'ai pas encore vue les singleton, je vais pouvoir découvrir sa!

Que veux tu dire par 800 std::string ?
les id's ne sont pas des string mais bien des nombres
Je ne pense pas que ce soit grave

[jblecanard]

Merci 1000 fois pour ce code. C'est exactement ce que je voulais.

Alors pouce mon message pour me donner des points

les id's ne sont pas des string mais bien des nombres
Je ne pense pas que ce soit grave

En effet, tu peux utiliser un int ou un unsigned int comme id. Comme ce sont des membres statiques des classes, ils occuperont de la place dans le segment données de ton exécutable. Pour 800 int, ça nous fait (800*4/1000) Mo = 3.2 Mo en plus dans ton exécutable/bibliothèque. Cela peut jouer si tu as des besoin de minimilisation de ton exécutable. Cela dit, avec un protocole qui gère 800 messages différents, difficile de faire très compact .

[Iradrille]

Pour 800 int, ça nous fait (800*4/1000) Mo = 3.2 Mo en plus dans ton exécutable/bibliothèque. Cela peut jouer si tu as des besoin de minimilisation de ton exécutable. Cela dit, avec un protocole qui gère 800 messages différents, difficile de faire très compact .

800 * 4 / 1024 = 3.125 Ko et non pas 3.2 Mo

[jblecanard]

Je n'ai pas encore vu les singleton, je vais pouvoir découvrir ça!

Attention à mon singleton, je n'ai pas protégé la copie ni l'assignement, ce qu'il faut faire normalement ! Je ne l'ai pas fait pour laisser le code le plus compact et le plus lisible possible.

[nostrora]

Désolé pour les fautes
Oui j'ai fait les pouces :p

Merci merci