Tree rewrites are fine, you can easily implement mark/sweep. Descend the tree after a batch of transforms marking reachable nodes, then iterate through the vector swapping any unique_ptr to an unmarked node with the last node in the vector, and reduce the end iterator by one. Count the number of pointers moved to the end, and then reduce the size of the vector by the count, destroying all the unmarked nodes.
Keean. On 14 Jun 2015 3:24 pm, "Jonathan S. Shapiro" <s...@eros-os.org> wrote: > Ah. Yes. That was the disconnect. Though I still don't know that I want > an AST vector. When I rewrite AST trees later, it won't be a desirable > retention mechanism. > > Shap > > On Sunday, June 14, 2015, Keean Schupke <ke...@fry-it.com> wrote: > >> I don't think you mean union in the same sense I do. I am not talking >> about a stack of type unions. >> >> I am talking about a stack that records unifications done (IE the >> union-find links made) so that they can be undone on backtracking. >> >> Keean. >> On 14 Jun 2015 1:31 pm, "Jonathan S. Shapiro" <s...@eros-os.org> wrote: >> >>> On Thu, Jun 11, 2015 at 6:34 AM, Keean Schupke <ke...@fry-it.com> wrote: >>> >>>> This is what the union-stack is for, storing the original pointer >>>> addresses when you move bits of the tree around... >>>> >>> >>> The union stack is, in some sense, the problem we are trying to get rid >>> of! >>> >>> shap >>> >>> _______________________________________________ >>> bitc-dev mailing list >>> bitc-dev@coyotos.org >>> http://www.coyotos.org/mailman/listinfo/bitc-dev >>> >>> > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
