Discussion :

[S.Ockham]

Bonsoir !
J'aimerai développer un générateur de code C++, et pour cela l'utilisateur entre les diverses informations le tout dans un arbre hiérarchique. En gros l'utilisateur définit ses classes, namespace, constante, méthodes, attributs et le tout produit un ensemble de fichier .hpp/.cpp

Par contre il y a une question à laquelle je n'arrive pas à trouver de solution élégante, admettons j'ai:
+ std (namespace)
----> string (classe)
----> vector (classe)
----> MAX_VECTOR_ELEMENT (constante)
Si je n'avais pas la constante, j'aurai généré un .hpp pour string et vector. Mais j'ai la constante qui appartient à std, donc que devrais-je générer ? Avez-vous une idée ?

Merci d'avance à tous, j'espère que cette question ne vous sembler pas inutile et stupide!

[koala01]

Salut, et bienvenue sur le forum.

Typiquement, les constantes doivent être définies... là où elles ont leur utilité.

MAX_VECTOR_ELEMENT est, visiblement, une constante qui s'applique... à la classe vector, et c'est donc de ce coté là qu'il faut envisager de la définir

Ensuite, la question qu'il faut se poser, c'est de savoir si cette constance est ou non "à usage interne" de la classe vector (comprend: si seules les fonctions de vector doivent la connaitre ou non).

La réponse à cette question te permettra de déterminer s'il est préférable de la déclarer dans un le fichier d'en-tête ou si seule sa définition dans le fichier d'implémentation est nécessaire

Ceci dit, cette manière d'envisager les choses doit être pondérée par le nombre de constantes dont tu envisages d'avoir besoin, et par les différents éléments qui devront y accéder.

Il est donc *possible* que la solution qui consisterait à regrouper les différentes constantes au sein d'un seul et même fichier *puisse* s'avérer être une option intéressante

[Davidbrcz]

J'aimerai développer un générateur de code C++, et pour cela l'utilisateur entre les diverses informations le tout dans un arbre hiérarchique. En gros l'utilisateur définit ses classes, namespace, constante, méthodes, attributs et le tout produit un ensemble de fichier .hpp/.cpp

Bonne chance, surtout si tu débutes (un générateur à squelette fixe n'est pas impossible mais demande quand même quelques bases).

+ std (namespace)
----> string (classe)
----> vector (classe)
----> MAX_VECTOR_ELEMENT (constante)
Si je n'avais pas la constante, j'aurai généré un .hpp pour string et vector. Mais j'ai la constante qui appartient à std, donc que devrais-je générer ? Avez-vous une idée ?

Pour faire simple: je ne comprends pas la question.
Que vient faire la constante, quelle rôle joue-t-elle ?

C'est p-e clair pour vous, mais pas pour nous.

[S.Ockham]

Bonsoir, merci pour ta réponse!

En fait, mon exemple n'était peut-être pas le plus explicite. Je voudrais pouvoir définir une constante dans un namespace, qui serait une constante du namespace. Donc pourquoi pas y acceder dans une des classes du namespace.

Mon soucis, c'est: ok j'ai mon namespace, mais que faire pour la génération au niveau du "constante dans le namespace." Dois-je créer un fichier "namespace.hpp" et "namespace.cpp" où je déclare et initialise la constante ?

[koala01]

Comme j'ai essayé de te le faire comprendre, tu dois la déclarer... là où elle est utile.

Si ta constante est destinée à être utilisée par plusieurs classes, il est sans doute préférable de créer un fichier d'en-tête (que je nommerai pour l'exemple "constants.hpp) proche de

Code :

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

1
2
3
4
5
6
7
8
9
#ifndef CONSTANTS_HPP
#define CONSTANTS_HPP
namespace MonEspaceDeNoms
{
extern const int constante1;
extern const int constante2;
/*...*/
} // namespace MonEspaceDeNoms
#endif // CONSTANTS_HPP

et un fichier d'implémentation (que je nommerai pour l'exemple "constants.cpp") proche de

Code :

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

1
2
3
4
5
6
namespace MonEspaceDeNoms
{
const int constante1 = 123456;
const int constante2 = 654321;
/*...*/
} // namespace MonEspaceDeNoms

et d'inclure constants.hpp dans les fichiers d'en-tête qui en ont besoin.

Par contre, si la constante n'est utile que pour une seule classe, définis la dans le fichier d'implémentation qui ... l'utilise, et déclare la éventuellement dans le fichiers d'en-tête ad-hoc, si c'est une constante à laquelle l'utilisateur doit avoir accès.

[S.Ockham]

D'accord, je pense comprendre.
En fait il y a deux cas:

+ MonNamespace
----> MaClasse1
----> MaClasse2
--------> MaConstante1
----> MaConstante2

Ici MaConstante1 n'est accessible que dans MaClasse2, elle peut donc appartenir au .hpp/.cpp de ce dernier. Par contre MaConstante2 a une visibilité plus grande, et elle doit donc appartenir à un fichier réunissant les "constantes de namespace" qui sont en fait les constantes de l'application. C'est cela ?

[koala01]

D'accord, je pense comprendre.
En fait il y a deux cas:

+ MonNamespace
----> MaClasse1
----> MaClasse2
--------> MaConstante1
----> MaConstante2

Ici MaConstante1 n'est accessible que dans MaClasse2, elle peut donc appartenir au .hpp/.cpp de ce dernier. Par contre MaConstante2 a une visibilité plus grande, et elle doit donc appartenir à un fichier réunissant les "constantes de namespace" qui sont en fait les constantes de l'application. C'est cela ?

On peut effectivement dire ça comme cela, oui...

Le principe d'organisation des fichiers d'en-tête est simple:

Chaque fichier ne doit exposer que le stricte minimum pour fournir les services que l'on attend de lui.

La classe string, par exemple, est une classe qui fournit les services de... gestion des chaines de caractères.

Il n'y aurait donc aucune raison valable pour qu'elle fournisse (du fait d'une inclusion de fichier) les services de... gestion de tableaux dynamiques (vector), par exemple.

Or, il n'est pas impossibles que ces deux classes utilisent les mêmes constantes ou, étant donné qu'il s'agit de deux classes template (std::string n'est jamais qu'un typedef spécialisant la std::basic_string pour... les caractères "char_t"), qu'elles utilisent des politiques ou des traits de politiques identiques.

On va donc séparer tout ce qui est commun aux std::string ou aux std::vector (voire, à d'autres classes encore) dans un (ou plusieurs !!!) fichier(s) clairement distincts, exposant chacun un aspect tout à fait particulier, et on incluera ces différents fichiers "partout où ce sera nécessaire" (dans le fichier <string> et / ou dans le fichier "vector" et / ou dans les autres fichiers qui en ont besoin).

[bruno_pages]

quel est le niveau d'abstraction des données d'entrée (classes ...) et leur représentation pour l'utilisateur (texte, graphique, ...) ?

vous avez regardé du coté d'UML ( je ne sais pas pourquoi je pense à lui en particulier ) ?

[S.Ockham]

Pigé!
Par contre, un point reste sombre, c'est ce dernier:

On va donc séparer tout ce qui est commun aux std::string ou aux std::vector (voire, à d'autres classes encore) dans un (ou plusieurs !!!) fichier(s) clairement distincts, exposant chacun un aspect tout à fait particulier,

Comment ça plusieurs fichiers ? Tu veux dire par exemple un fichier pour les constantes communes, un autre pour les enum ? Parce que là enfaite, ça va surtout dépendre de comment l'utilisateur voit les choses non ?

Sinon pour l'abstraction, pour la moment ça sera simple: l'utilisateur entre le tout sous forme d'un arbre. Ensuite dès que j'aurai réussi à générer un code C++ à partir de ça, j'aimerai bien générer un diagramme de classe en UML ... Et après pourquoi pas m'atteler à la tache UML vers C++ ... Enfin, déjà réussir les relativement petits objectifs, on verra la suite après!

[koala01]

Comment ça plusieurs fichiers ? Tu veux dire par exemple un fichier pour les constantes communes, un autre pour les enum ? Parce que là enfaite, ça va surtout dépendre de comment l'utilisateur voit les choses non ?

Non, je veux dire qu'il ne faut mettre dans chaque fichier que le minimum requis pour assurer un service particulier de manière "atomique".

Imagine que tes différentes classes utilisent (ou non) trois ou quatre politiques qui sont totalement transversales (qui n'ont à priori aucun rapport les unes par rapport aux autres).

Il ne faut pas que, en incluant le fichier dans lequel une politique particulière est définie, tu n'en vienne à... exposer une autre politique qui n'est pas forcément nécessaire.

Tu vas donc définir ces différentes politiques dans... des fichiers clairement séparés, et, par conséquent, tu placera les constantes dans... le fichier de la politique qui les utilisent.

Il faut comprendre que les constantes, comme toutes les variables, d'ailleurs, ne prennent du sens qu'au travers de l'utilisation qui en est faite.

Par exemple, la valeur 3.1415626 (c'est "Pi" ) ne prend du sens que parce qu'on va l'utiliser dans le domaine des mathématiques de plus ou moins haut niveau, et ne sera donc utile qu'à coté des fonctions / classes correspondantes (périmètre ou superficie de cercles / disques, calcul trigonométrique, ...)

Il ne sert donc pas "à grand chose" de se balader avec cette constante et les fonctions qui l'utilisent si c'est pour ... manipuler des chaines de caractères.

Tu en arrive donc à placer dans un fichier ce qui est éventuellement commun à plusieurs classes, mais, s'il y a dans ce fichier quelque chose qui n'est pas utilisé par toutes les classes, il faut le placer dans un autre fichier de manière à pouvoir ne l'inclure et de pouvoir n'en disposer qu'en cas de besoin.

C'est pour cela que je parle de "un ou plusieurs fichier(s) clairement distinct(s)"

[bruno_pages]

3.1415626 (c'est "Pi" )

presque (le premier 6 devrait être un 9)

pour le reste je suis d'accord avec koala01, il faut donc (entre autre) choisir si l'arbre représente le déploiement avec le contenu des fichiers ou l'organisation des namespaces / classes etc), car :

les namespaces peuvent s'inclure (ie un namespace défini dans un autre etc)

les classes aussi peuvent s'inclure

un fichier peut contenir plusieurs séries de namespaces les uns à la suite des autres avec ce qui est défini dedans, ou bien sur aucun

un fichier peut aussi contenir plusieurs classes ou aucune

le contenu total des définitions dans un namespace peut être réparti dans plusieurs fichiers

les définitions des opérations peuvent aussi être réparti dans plusieurs fichiers (possible mais pas vraiment recommandé)

etc...

on pourrait aussi imaginer plusieurs vues, c.a.d. un explorateur montrant la définition des fichiers et un autre l'organisation des namespace / classes ...

[koala01]

presque (le premier 6 devrait être un 9)

oui, c'est mon doigt qui a glissé... le 6 est décidément trop près du 9 sur un pavé numérique