Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Personally, I'd go with the RenderState approach.</p> <p>Alternatively, if there's a well-defined set of Render-only functions that all require access to the same data, I'd seriously investigate pulling those into their own DocumentRenderer class that contains both the appropriate methods and the appropriate member variables. (This is similar to Fowler's <a href="http://www.refactoring.com/catalog/replaceMethodWithMethodObject.html" rel="nofollow noreferrer">"method object" refactoring</a>.)</p> <p>C++ doesn't have nested functions, but local classes can serve as an imperfect solution. (Imperfect because local classes' methods cannot access variables of the enclosing class and because they can't be used to instantiate templates.) A local class is simply a class that's declared, along with its methods, within the body of a function. Herb Sutter discusses local classes in more detail <a href="http://www.gotw.ca/gotw/058.htm" rel="nofollow noreferrer">here</a>.</p> <p>Local classes are used to implement Boost's <a href="http://www.boost.org/doc/libs/1_41_0/libs/scope_exit/doc/html/index.html" rel="nofollow noreferrer">ScopeExit</a> library. ScopeExit's reviewers <a href="http://lists.boost.org/boost-announce/2008/05/0190.php" rel="nofollow noreferrer">noted that</a> ScopeExit "suggests a method for creating a general closure mechanism as a library," so if you aren't happy with a RenderState or DocumentRenderer approach, ScopeExit's implementation may give you some ideas for closures in C++.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload