Discussion :

[gilims]

Bonjour à tous !

Je travailles actuellement sur un projet qui m'a amené à la question suivante : "Comment bien gêrer les tables de données constantes ?".

Je m'explique. Prenons le cas d'une personne. Une personne peut forcemment être soit un homme soit une femme. Elle a aussi en général une catégorie socio-professionnel par exemple. Elle habite aussi dans une ville. (J'essaie d'exagerer le tout pour voir les différents cas de figures).

De mon point de vue, je créerais un namespace pour chaque cas avec un énum, comme cela :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
namespace Gender 
{
enum{Homme=1, Femme =2}
}
 
namespace SocioProf
{
enum{Liberal=1,Medecin=2, Policier=3}
}
namespace Ville
{
enum{Paris=1,Marseille=2,Lyon=3}
}

Je pense qu'on est d'accord pour dire que dans le cas des villes, la structure est mauvaise car il y a trop de possibilités à prendre en compte.
J'en appelle à vous pour me dire comment gêrer le mieux possible ce type de données.
Merci d'avance

[6-MarViN]

Faire un objet. La programmation objet est l'une des plus intuitives, justement parce qu'elle permet de transcrire des situation réelle en programme en utilisant virtuellement ce qu'on utilise physiquement : des objets.

Tu pourrais peut-être faire la chose suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class        Person
{
 private:
  std::string  firstName;
  std::string  lastName;
  eSex         sex;
  std::string  city;
  ...
}

Et ça te constitue une personne.

[gilims]

Je suis complètement d'accord avec toi 6-MarViN. Pour représenter une personne en C++, l'objet reste le meilleur choix. Cependant le sujet du post n'est pas là. J'ai du mal m'exprimer .

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class        Person
{
 private:
  std::string  firstName;
  std::string  lastName;
  eSex         sex;
  std::string  city;
  ...
}

Ceci est une bonne description d'une personne. Mais si on a besoin de limiter les valeurs possibles de sex et city par exemple, il est nécessaire de définir un tableau des valeurs possibles. La question est de savoir comment bien définir en C++ ces tableaux là, en fonction de nombre de possibilités.

Pour le sexe, comme il n'y a que 2 cas possibles, un enum suffira. Mais comment faire si l'on commence à avoir beaucoup de possibilité ??

[oodini]

Ben dans le cas de la ville, il faut utiliser un string, et pas un enum.

[6-MarViN]

La question est de savoir comment bien définir en C++ ces tableaux là, en fonction de nombre de possibilités.

Pour le sexe, comme il n'y a que 2 cas possibles, un enum suffira. Mais comment faire si l'on commence à avoir beaucoup de possibilité ??

Et ben tu fais un tableau de tout les diables avec toutes les possibilités.

Honnêtement a part définir toutes les possibilités, je vois mal comment tu pourrais procéder.

[gilims]

Et ben tu fais un tableau de tout les diables avec toutes les possibilités.

Honnêtement a part définir toutes les possibilités, je vois mal comment tu pourrais procéder.

On est forcemment obligé à un moment ou un autre de définir toutes les villes, on est d'accord.

- Une classe qui représente une grande table de valeurs possibles
- Une factory pour les personnes qui a un membre du type de la classe précédente.
- En option, un objet table partagé par toutes les personnes.

Je n'ai jamais entendu parler de factory auparavant. Aurais-tu quelques liens à me transmettre à ce sujet. J'ai chercher sur Google mais j'ai trouvé que sur le design pattern factory. C'est ca ??

De plus, il serait idéal de découpler la compilation et le contenu de la table.

A partir de quelques quantités de données vaut-il mieux passer en données externes (via un fichier) plutot qu'en interne?

Comme le dit oodini : il faut utiliser, pour une ville, le même type que la donnée stockée, soit std::string. Il suffit alors de faire des vérifications de cohérence avec la table lorsque c'est nécessaire. Il ne faut pas stocker l'index (comme on le ferait avec une base de donnée), car il peut se décaler quand la table va évoluer

Je suis d'accord, mais seulement dans le cas où les données sont externes. Si elles sont enregistrées lors de la compilation, l'index n'est pas censé changer.

De mon coté, j'avais fait l'erreur (de jeunesse dira-t-on ) de créer une structure de donnée constante dans un header contenant mes informations. Je recopiais donc pour chaque personne les informations contenues dans la structure plutot que juste garder l'index dans l'objet "personne" et récupérer directement la valeur dans la structure de donnée.
Rassurer moi juste en me confirmant que c'est une erreur de faire ca

J'ai donc deux questions me venant à l'esprit :
Quel est le cout en :
1. performance à l'execution
2. temps de compilation
3. taille de l'executable
4. cout mémoire
des cas de figures suivant :
1. Une énumeration
2. Une structure de données constante définit dans un header
3. Un fichier externe
en extrapolant sur des cas généraux/

Comment correctement gérer des données plus complexes ?

Pour mieux situer la problématique, je travaille sur des acides aminés. Chacun possède un nom, une lettre, un poids, un certain nombre d'atome, des propriétés pour chaque atome (qui diffère en fonction des acides aminés), etc etc. Il y en a 22 de bases, plus les acides aminés modifiés que je devrais rajouter au compte goutte. Au final j'essaie de comprendre comment manipuler au mieux ces données là.

Merci encore

[Steph_ng8]

Salut.

Je n'ai jamais entendu parler de factory auparavant. Aurais-tu quelques liens à me transmettre à ce sujet. J'ai chercher sur Google mais j'ai trouvé que sur le design pattern factory. C'est ca ??

C'est bien ça.
Tu peux déjà aller voir ce tutoriel: Présentation des principaux design patterns en C++

[jblecanard]

J'ai chercher sur Google mais j'ai trouvé que sur le design pattern factory. C'est ca ??

Oui je parlais bien du design pattern factory.

Je suis d'accord, mais seulement dans le cas où les données sont externes. Si elles sont enregistrées lors de la compilation, l'index n'est pas censé changer.

Non, ce n'est pas tout à fait ça. En fait, tu peux stocker l'index si la liste n'évolue pas pendant toute la durée de vie de l'objet personne. Si tu fais de la persistance sur cet objet (stockage dans un fichier), tu comprend qu'il va falloir penser le problème un peu mieux.

Pour les perfos : Au niveau de la comparaison en terme de perfos, et bien... difficile de te répondre sans mieux connaître ton programme ni la taille des données manipulées. Tu as vraiment des contraintes en terme de perfs et de taille de l'exécutable ? Vu le sujet, ça ne ressemble pas à de l'embarqué.

[jblecanard]

Mais comment faire si l'on commence à avoir beaucoup de possibilité ??

Salut

Je trouve ce post intéressant, car il soulève plusieurs problèmes. enum n'est pas adapté pour les grandes plages de valeur, et surtout enum ne permet de ne représenter que des entiers non signés en mémoire, ce qui est quand même très limitant. Souvent, ce genre de problème est résolu par l'usage d'une base donnée. Les données sont stockées dans une table et on ne peut ne stocker dans les objets qu'une référence à l'entrée correspondante dans la table.

Si on aborde la chose d'un point de vue programme standalone, il vaut mieux utiliser une véritable structure de donnée runtime que l'on remplira au moment opportun. Une fois ce postulat effectué, il reste plusieurs problématiques :

Comment gérer l'accès à la table ?

Avec un enum, l'include du header suffit. Mais avec une donnée construite au runtime, ce n'est pas possible. On a vite fait de tomber dans le piège de l'accès global et d'écrire un singleton. Une solution possible est d'avoir :

- Une classe qui représente une grande table de valeurs possibles
- Une factory pour les personnes qui a un membre du type de la classe précédente.
- En option, un objet table partagé par toutes les personnes.

Comment maintenir la table ?

La table va sûrement évoluer et s'enrichir. De plus, il serait idéal de découpler la compilation et le contenu de la table. On peut donc par exemple stocker la liste des entrées possibles dans un fichier.

Comment stocker la donnée pour chaque personne ?

Comme le dit oodini : il faut utiliser, pour une ville, le même type que la donnée stockée, soit std::string. Il suffit alors de faire des vérifications de cohérence avec la table lorsque c'est nécessaire. Il ne faut pas stocker l'index (comme on le ferait avec une base de donnée), car il peut se décaler quand la table va évoluer.