Problème de conception avec des données presque statiques

Question

Je développe un interpréteur d'un langage de programmation simple.

1. Il existe des données dynamiques structurées en arborescence , chacun des nœuds de données ayant un objet-type associé (détenu) .
2. Il existe plusieurs types de types - ListType, StructType etc. - et un spécial - TypeRef . Le TypeRef contient un nom (une chaîne) qui fait référence à un type concret.
3. Il existe une carte (presque) globale (dictionnaire) - je l'appelle environnement - (std::map<string, Type*>) qui traduit les noms de types en objets-types.

Le problème est qu’il peut y avoir plusieurs programmes chargés et que chacun d’eux peut avoir différents types associés aux mêmes noms. Cette simple hypothèse rend impossible la création d’un environnement global (statique), qui serait sinon une solution parfaite.

Par conséquent, il semble que j'ai besoin d'un (# 1) pointeur sur un environnement dans chaque objet-type ou (# 2) pour effectuer chaque opération dans le contexte de l'environnement (par exemple en le fournissant partout comme premier argument ).

Les problèmes que je vois:
(N ° 1) Redondance des informations, car tous les nœuds de données connectés auraient le même environnement. Les environnements ne seraient différents que pour des données strictement séparées.
(# 2) Beaucoup de passage trivial de l'environnement aux sous-programmes, obscurcissant le code.

Il me semble que ce problème correspond à un schéma général que j'appellerais des données presque statiques . Des idées quelle serait la meilleure solution?

Answer 1

L’idée d’utiliser un stockage local au thread est intéressante, mais j’ai finalement trouvé une autre solution:

J'utilise les types en deux phases: d'abord, ils sont tous créés, puis ils sont & "compilés &"; La compilation nécessite un environnement, mais n'est effectuée qu'une fois. Cela consiste à traduire tous les noms de types en objets-types appropriés. Après la compilation, l’environnement n’est plus nécessaire.

Néanmoins, je pense qu’il s’agit toujours d’une solution de contournement plutôt que d’une solution générale.

Answer 2

Qu'est-ce qui sépare les environnements? S'il s'agit du contexte d'exécution (les objets dans un contexte n'appellent que ceux du même contexte), vous pouvez utiliser un fil par environnement et stocker le & "Local-globals &"; dans un stockage local de threads (ou simplement une carte globale avec des clés identifiant des threads).

Cela présente certains inconvénients. D'une part, cela ne fonctionne pas s'il y a des appels entre contextes. Et bien sûr, cela vous oblige à adopter un modèle fileté.

Answer 3

Vous voudrez peut-être avoir deux stockages de types: un global pour les types concrets et un local pour TypeRef. Le stockage local doit être placé dans le contexte d’un programme en cours d’analyse.