Problema de diseño con datos casi estáticos.

Question

Estoy desarrollando un intérprete de un lenguaje de programación simple.

1. Hay datos dinámicos estructurados en árbol , donde cada uno de los nodos de datos tiene un objeto-tipo asociado (propiedad).
2. Hay varios tipos de tipos: ListType, StructType, etc., y uno especial: TypeRef . TypeRef contiene un nombre (una cadena) que se refiere a algún tipo concreto.
3. Hay un mapa (diccionario) global (casi): lo llamo el entorno - (std::map<string, Type*>) que traduce los nombres de tipo en objetos de tipo.

El problema es que puede haber varios programas cargados y cada uno de ellos puede tener diferentes tipos asociados con los mismos nombres. Esta suposición única hace que sea imposible tener un entorno global (estático), que de lo contrario sería una solución perfecta.

Por lo tanto, parece que necesito (# 1) un puntero a un entorno en cada tipo de objeto o (# 2) para realizar todas las operaciones en el contexto del entorno (por ejemplo, proporcionándolo en todas partes como primer argumento ).

Los problemas que veo:
(# 1) Redundancia de información, porque todos los nodos de datos conectados tendrían el mismo entorno. Los entornos solo serían diferentes para datos estrictamente separados.
(# 2) Mucho paso trivial del entorno a subrutinas, ofuscando el código.

Me parece que este problema coincide con un patrón general que llamaría datos casi estáticos . ¿Alguna idea de cuál sería la mejor solución?

Answer 1

La idea de usar el almacenamiento local de subprocesos es interesante, pero finalmente terminé con otra solución:

Utilizo los tipos en dos fases: primero se crean y luego se " compilan " ;. La compilación requiere un entorno, pero se realiza solo una vez. Consiste en traducir todos los nombres de tipo en objetos de tipo adecuados. Después de la compilación, el entorno ya no es necesario.

Sin embargo, creo que aún es más una solución que una solución general.

Answer 2

¿Qué separa los ambientes? Si es el contexto de ejecución (los objetos en un contexto solo llaman unos en el mismo contexto), entonces puede usar un hilo por entorno y almacenar el & Quot; local-globals & Quot; en un almacenamiento local de subprocesos (o simplemente un mapa global con claves que son ID de subproceso).

Esto tiene algunas desventajas. Por un lado, no funciona si hay llamadas de contexto cruzado. Y, por supuesto, te obliga a un modelo roscado.

Answer 3

Es posible que desee tener dos almacenamientos de tipos: uno global para tipos concretos, uno local para TypeRefs. El almacenamiento local debe ponerse en el contexto de un programa que se está analizando actualmente.