Discussion :

[Klaim]

Herb Sutter s'attaque maintenant (avec sa communauté) au problème de cette discussion, donc il va ya bientot y avoir une guideline officielle :

http://herbsutter.com/2012/01/20/got...ifficulty-310/

[Steph_ng8]

@jblecanard Implémenter plusieurs solutions ?
Hum…
Oui, pourquoi pas, après tout.
C'est sûr que ça va prendre du temps, mais décider quelle solution avant de commencer à implémenter quoi que ce soit en prendra également.
Je vais voir ce que ça donne…

@Klaim Oh, il lisent les messages de ce forum ?
Cool…

Plus sérieusement, merci pour le lien.
Je regarderai ça en détails lorsque j'aurai du temps.

[CedricMocquillon]

Salut,

Perso, j'utilise une collection de shared_ptr avec des map au niveau d'un méta objet et des shared_ptr quasiment partout (sauf pour les cas où un objet possède un sous objet).

Dans ton cas:
- pour les variables et constantes
=> des map dans programme avec des accesseurs prenant les clefs (des strings) comme paramètre et renvoyant les variables et constantes correspondantes

- pour la classe littéral
=> une collection de shared_ptr de termes avec une méthode add_argument qui prend un shared_ptr<terme> :
lorsque l'on ajoute un terme constant ou variable, on utilise les accesseurs de la classe programme,
lorsque l'on ajoute un terme entier, on utilise directement un make_shared<Entier>(valeur) (pour moi, les entiers devraient être crées "à la volée", sauf si tu as 10000 fois le même entier référencé et des problèmes de mémoire)

Remarque:
+ Si un littéral n'a de sens qu'au sein d'une règle, alors collection de std::unique_ptr dans règle,
+ S'il peuvent être partagé entre plusieurs règles au sein d'un même programme et qu'il y a moyen de les identifier par une clef alors map de clef, shared_ptr de littéral dans programme

Cette remarque s'applique également à la classe règle

- pour la classe règle
=> une collection de weak_ptr (ou de pointeurs nus) de variables (mais si on utilise des shared, cela ne change rien fonctionnellement)
=> pour les littéraux cf ci dessus

- pour les symboles de fonction
=> une map dans programme avec comme clef le nom de fonction


Cette approche peut être pénalisante si tu crées et détruit énormément de règles et qu'au bout d'un moment, tu te retrouves avec des variables qui ne servaient que pour les premières règles crées et qui ne sont donc plus que référencées par programme. Si tu es dans ce cas, il faudra mettre en place une politique de "nettoyage" du programme supprimant tout les shared_ptr dont unique renvoie true.
Après il faut voir le compromis à trouver suivant les cas d'utilisation du programme: préfères-tu avoir une faible consommation mémoire (i.e. nettoyer fréquemment ton programme) quitte à reconstruire des variables après coup ou pas?

Enfin théoriquement (i.e. en utilisant normalement un programme) tu ne devrais pas avoir de "sac de nœuds" qui créerait des cycles. Après rien n'empêche un utilisateur de créer une variable dont le terme substitut est la variable elle même...

[Steph_ng8]

Merci CedricMocquillon, on va dire que c'est l'intention qui compte…

Au risque de me répéter, le problème de stockage se pose juste pour les classes « Entier », « Prédicat » et « Symbole de fonction ».
Pour ce qui est des « Termes fonctionnels », je peux apporter une petite précision par rapport à mon dernier message.
Un « Terme fonctionnel » est utilisé par un (et un seul) « Littéral », et sa durée de vie ne dépasse pas celle du « Littéral » qui l'utilise.
Donc finalement, je pense que l'on peut dire que les « Termes fonctionnels » ont pour propriétaire les « Littéraux ».

(pour moi, les entiers devraient être crées "à la volée", sauf si tu as 10000 fois le même entier référencé et des problèmes de mémoire)

Évidemment que les « Entiers » sont créés à la volée.
Mais durant une exécution, certains peuvent êtres utilisés puis inutilisés plusieurs fois.
Les garder en mémoire permettrait d'éviter de les recréer.

- pour les symboles de fonction
=> une map dans programme avec comme clef le nom de fonction

J'ai déjà expliqué ce qui me dérangeait avec cette solution.
Si tu n'expliques pas ce qui motive ce choix, il ne m'est d'aucune valeur.
Entre parenthèses, le nom d'un symbole de fonction ne suffit pas à l'identifier…

Après il faut voir le compromis à trouver suivant les cas d'utilisation du programme: préfères-tu avoir une faible consommation mémoire (i.e. nettoyer fréquemment ton programme) quitte à reconstruire des variables après coup ou pas?

Ce ne sont pas les variables qui seront reconstruites, mais la consommation mémoire peut être une ressource critique, en effet.
Ceci dit, dans mon cas je crois bien que la durée d'exécution est encore plus critique.

Après rien n'empêche un utilisateur de créer une variable dont le terme substitut est la variable elle même...

Normalement, cela ne devrait pas être possible.