On Tue, 15 Sep 2009, John Peterson wrote: > MeshProxy is derived from MeshBase so that it's forced to re-implement > all the right interfaces.
But as you said before, the interfaces include provision of non-const Node and Elem pointers and references, which other code might hang on to and change at its leisure. We could define an ElemProxy subclass of Elem, but that's a bit inefficient, and I don't think there's any good way to do the same with Node, which is what everyone doing moving mesh stuff is going to touch. Here's a thought: Derek's change counter suggestion is probably misleading in MeshBase, but it might be suited for MeshRefinement. That would make it clearer that the counter was just tracking refinement/coarsening changes, and not anything like mesh movement. On the other hand, people often create and destroy MeshRefinement objects willy-nilly since they don't currently store any state beyond refinement heuristic parameters; it would be a pretty easy application bug to trust a change count that was getting deleted after and reset before each refinement step. --- Roy ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
