Giovanni Piero Deretta <gpderetta <at> gmail.com> writes:
I use boost lambda expression extensively, and I have a love/hate relationship with them. When you finally get a (complex) lambda to compile it might even be elegant and even readable, but getting there requires an inordinate amount of time.
:-)
I do not have time right now for a review (I will try late this evening), but I think that the "inline" lambda capabilities of ScopeExit and its ScopeGuard-like functionality should be decoupled. The trick used by ScopeExit could be much more useful as a generalized (named) closure mechanism. These closures could then be used with the classic ScopeGuard idiom, to emulate what ScopeExit does right now, but could also replace most usages of boost lambda. Anyone would find such a mechanism useful? Alexander, do you think that it would be hard to extend ScopeExit to a generalized closure? I have done some experiments in the past with something like that and it seemed doable.
The problem is that ScopeExit relies on local structs which can't be used in templates. If you look at Implementation section ( http://tinyurl.com/2gerqy ) you'll notice params_1_t and scope_exit_body_t local structures. Though, I see how it can be avoided: (void*) new params_1_t(...). I should play with this idea. May be I'll be able to come up with a good syntax for a generalized closure ;-) -- Alexander