Je complète avec un exemple d'usage que j'ai eu en vrai. Je manipule un très gros graph dans une interface graphique. Tous les paramètres de l'interface, jusqu'au champs qui a le focus, sont stockés dans un arbre. Pour info, une fois sérialisé (en binaire), le graph fait plusieurs centaines de Mo, voir quelques Giga. Chaque modification crée une nouvelle copie de cette structure et est ajouté dans une liste de modification (en fait c'est un graph). Faire annuler revient à revenir en arrière d'un cran dans le graph. Faire "redo" revient à avancer en avant d'un cran dans le graph. En moyenne chaque copie du graph coûte O(log(n)) en mémoire, ce qui est négligeable et permet de conserver une grande quantité d'étape d'undo/redo. On peut même les sauvegarder avec le fichier. C'est gratuit à faire avec des structures persistantes, modulo qu'en C++ je dois me balader avec des shared_ptr de partout, mais cela fonctionne.
[^] # Re: Structures non mutables performantes
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 3.
Très bon ;)
Je complète avec un exemple d'usage que j'ai eu en vrai. Je manipule un très gros graph dans une interface graphique. Tous les paramètres de l'interface, jusqu'au champs qui a le focus, sont stockés dans un arbre. Pour info, une fois sérialisé (en binaire), le graph fait plusieurs centaines de Mo, voir quelques Giga. Chaque modification crée une nouvelle copie de cette structure et est ajouté dans une liste de modification (en fait c'est un graph). Faire annuler revient à revenir en arrière d'un cran dans le graph. Faire "redo" revient à avancer en avant d'un cran dans le graph. En moyenne chaque copie du graph coûte O(log(n)) en mémoire, ce qui est négligeable et permet de conserver une grande quantité d'étape d'undo/redo. On peut même les sauvegarder avec le fichier. C'est gratuit à faire avec des structures persistantes, modulo qu'en C++ je dois me balader avec des
shared_ptrde partout, mais cela fonctionne.