On 15/09/10 15:56, Lorenzo Caminiti wrote:
2) I will require users to use `this_` instead of `this` inside local functions when the enclosing object is bound. The local function is internally implement as a _static_ member of a local class so `this` will simply not be available and it cannot be used by mistake instead of `this_`.
I'm puzzled; you say you're using static functions here but the examples you give don't, and in particular this seems incompatible with the "pass as template parameters" trick and recursion.
3) I will use the `bind` preprocessor "keyword" for the parenthesized syntax as in `(bind)(...)` and `(const bind)(...)`. `bind` is more readable than `bound` or `closure` (plus I do not know English well enough to figure out if `bound` is more correct because it is used in declarative as supposed as imperative context... English native speakers: Help me!).
I think it can be interpreted as either imperative (instructing the macro to bind things) or declarative (stating that the things are bound). I wouldn't worry too much.
5) When used within a template, the macros `BOOST_LOCAL_FUNCTION_TPL`, `BOOST_LOCAL_CONST_TPL`, etc will need to be used (otherwise you get a compiler error). This is necessary for the library to apply `typename` from within the template where the type determination is context depend (and given that C++ does not allow to use `typename` outside templates). The same convention is used by Boost.ScopeExit, etc.
I think C++0x allows the typename keyword in more contexts, so you might be able to get away with it having only one variety there. Probably not worth the trouble, though, given that the library is somewhat made obsolete by C++0x features anyway... John Bytheway