|  | Home | Libraries | People | FAQ | More | 
This section illustrates advanced usage of this library. At the bottom there is also a list of known limitations of this library.
        This library allows to specify default values for the local function parameters.
        However, the usual C++ syntax for default parameters that uses the assignment
        symbol = cannot be used. [17] The keyword default
        is used instead:
      
parameter-type parameter-name, defaultparameter-default-value, ...
        For example, let's program a local function add(x,
        y)
        where the second parameter y
        is optional and has a default value of 2
        (see also add_default.cpp):
      
int BOOST_LOCAL_FUNCTION(int x, int y, default 2) { // Default parameter. return x + y; } BOOST_LOCAL_FUNCTION_NAME(add) BOOST_TEST(add(1) == 3);
        Programmers can define a WITH_DEFAULT
        macro similar to the following if they think it improves readability over
        the above syntax (see also add_with_default.cpp):
        [18]
      
#define WITH_DEFAULT , default
int BOOST_LOCAL_FUNCTION(int x, int y WITH_DEFAULT 2) { // Default. return x + y; } BOOST_LOCAL_FUNCTION_NAME(add) BOOST_TEST(add(1) == 3);
        The C++ preprocessor does not allow commas ,
        within macro parameters unless they are wrapped by round parenthesis () (see the Boost.Utility/IdentityType
        documentation for details). Therefore, using commas within local function
        parameters and bindings will generate (cryptic) preprocessor errors unless
        they are wrapped with an extra set of round parenthesis ()
        as explained here.
      
| ![[Note]](../../../../../doc/src/images/note.png) | Note | 
|---|---|
| 
          Also macro parameters with commas wrapped by angular parenthesis  | 
        In addition, local function parameter types cannot start with non-alphanumeric
        symbols (alphanumeric symbols are A-Z, a-z,
        and 0-9). [19] The library will generate (cryptic) preprocessor errors if a
        parameter type starts with a non-alphanumeric symbol.
      
Let's consider the following example:
void BOOST_LOCAL_FUNCTION( const std::map<std::string, size_t>& m, // (1) Error. ::sign_t sign, // (2) Error. const size_t& factor, default key_sizeof<std::string, size_t>::value, // (3) Error. const std::string& separator, default cat(":", " ") // (4) OK. ) { ... } BOOST_LOCAL_FUNCTION_NAME(f)
        (1) The parameter type const
        std::map<std::string, size_t>& contains a comma ,
        after the first template parameter std::string.
        This comma is not wrapped by any round parenthesis ()
        thus it will cause a preprocessor error. [20] The Boost.Utility/IdentityType
        macro BOOST_IDENTITY_TYPE((type-with-commas)) defined in the boost/utility/identity_type.hpp
        header can be used to wrap a type within extra parenthesis () so to overcome this problem:
      
#include <boost/utility/identity_type.hpp> void BOOST_LOCAL_FUNCTION( BOOST_IDENTITY_TYPE((const std::map<std::string, size_t>&)) m, // OK. ... ) { ... } BOOST_LOCAL_FUNCTION_NAME(f)
        This macro expands to an expression that evaluates (at compile-time) exactly
        to the specified type (furthermore, this macro does not use variadic macros
        so it works on any C++03
        compiler). Note that a total of two set of parenthesis ()
        are needed: The parenthesis to invoke the BOOST_IDENTITY_TYPE(...) macro plus the parenthesis to wrap the
        type expression (and therefore any comma ,
        that it contains) passed as parameter to the BOOST_IDENTITY_TYPE((...)) macro. Finally, the BOOST_IDENTITY_TYPE macro must be prefixed
        by the typename keyword typename BOOST_IDENTITY_TYPE(parenthesized-type) when used together with the BOOST_LOCAL_FUNCTION_TPL
        macro within templates.
      
| ![[Note]](../../../../../doc/src/images/note.png) | Note | 
|---|---|
| 
          Often, there might be better ways to overcome this limitation that lead
          to code which is more readable than the one using the  | 
        For example, in this case a typedef
        from the enclosing scope could have been used to obtain the following valid
        and perhaps more readable code:
      
typedef std::map<std::string, size_t> map_type; void BOOST_LOCAL_FUNCTION( const map_type& m, // OK (and more readable). ... ) BOOST_LOCAL_FUNCTION_NAME(f)
        (2) The parameter type ::sign_t starts with the non-alphanumeric
        symbols :: thus it will generate
        preprocessor errors if used as a local function parameter type. The BOOST_IDENTITY_TYPE macro can also be used
        to overcome this issue:
      
void BOOST_LOCAL_FUNCTION( ... BOOST_IDENTITY_TYPE((::sign_t)) sign, // OK. ... ) { ... } BOOST_LOCAL_FUNCTION_NAME(f)
| ![[Note]](../../../../../doc/src/images/note.png) | Note | 
|---|---|
| 
          Often, there might be better ways to overcome this limitation that lead
          to code which is more readable than the one using the  | 
        For example, in this case the symbols ::
        could have been simply dropped to obtain the following valid and perhaps
        more readable code:
      
void BOOST_LOCAL_FUNCTION( ... sign_t sign, // OK (and more readable). ... ) { ... } BOOST_LOCAL_FUNCTION_NAME(f)
        (3) The default parameter value key_sizeof<std::string, size_t>::value
        contains a comma , after the
        first template parameter std::string.
        Again, this comma is not wrapped by any parenthesis ()
        so it will cause a preprocessor error. Because this is a value expression
        (and not a type expression), it can simply be wrapped within an extra set
        of round parenthesis ():
      
void BOOST_LOCAL_FUNCTION( ... const size_t& factor, default (key_sizeof<std::string, size_t>::value), // OK. ... ) { ... } BOOST_LOCAL_FUNCTION_NAME(f)
        (4) The default parameter value cat(":", " ") is instead fine because it contains a comma
        , which is already wrapped by
        the parenthesis () of the function
        call cat(...).
      
        Consider the following complete example (see also macro_commas.cpp):
      
void BOOST_LOCAL_FUNCTION( BOOST_IDENTITY_TYPE((const std::map<std::string, size_t>&)) m, BOOST_IDENTITY_TYPE((::sign_t)) sign, const size_t& factor, default (key_sizeof<std::string, size_t>::value), const std::string& separator, default cat(":", " ") ) { // Do something... } BOOST_LOCAL_FUNCTION_NAME(f)
        Local functions are function objects so it is possible to assign them to
        other functors like Boost.Function's
        boost::function in order to store the local function
        into a variable, pass it as a parameter to another function, or return it
        from the enclosing function.
      
        For example (see also return_assign.cpp):
      
void call1(boost::function<int (int) > f) { BOOST_TEST(f(1) == 5); } void call0(boost::function<int (void)> f) { BOOST_TEST(f() == 5); } boost::function<int (int, int)> linear(const int& slope) { int BOOST_LOCAL_FUNCTION(const bind& slope, int x, default 1, int y, default 2) { return x + slope * y; } BOOST_LOCAL_FUNCTION_NAME(lin) boost::function<int (int, int)> f = lin; // Assign to local variable. BOOST_TEST(f(1, 2) == 5); call1(lin); // Pass to other functions. call0(lin); return lin; // Return. } void call(void) { boost::function<int (int, int)> f = linear(2); BOOST_TEST(f(1, 2) == 5); }
| ![[Warning]](../../../../../doc/src/images/warning.png) | Warning | 
|---|---|
| As with C++11 lambda functions, programmers are responsible to ensure that bound variables are valid in any scope where the local function object is called. Returning and calling a local function outside its declaration scope will lead to undefined behaviour if any of the bound variable is no longer valid in the scope where the local function is called (see the Examples section for more examples on the extra care needed when returning a local function as a closure). It is always safe instead to call a local function within its enclosing scope. | 
        In addition, a local function can bind and call other local functions. Local
        functions should always be bound by constant reference const
        bind&
        to avoid unnecessary copies. For example, the following local function inc_sum binds the local function inc so inc_sum
        can call inc (see aslo transform.cpp):
      
int offset = 5; std::vector<int> v; std::vector<int> w; for(int i = 1; i <= 2; ++i) v.push_back(i * 10); BOOST_TEST(v[0] == 10); BOOST_TEST(v[1] == 20); w.resize(v.size()); int BOOST_LOCAL_FUNCTION(const bind& offset, int i) { return ++i + offset; } BOOST_LOCAL_FUNCTION_NAME(inc) std::transform(v.begin(), v.end(), w.begin(), inc); BOOST_TEST(w[0] == 16); BOOST_TEST(w[1] == 26); int BOOST_LOCAL_FUNCTION(bind& inc, int i, int j) { return inc(i + j); // Call the other bound local function. } BOOST_LOCAL_FUNCTION_NAME(inc_sum) offset = 0; std::transform(v.begin(), v.end(), w.begin(), v.begin(), inc_sum); BOOST_TEST(v[0] == 27); BOOST_TEST(v[1] == 47);
        It is possible to nest local functions into one another. For example (see
        also nesting.cpp):
      
int x = 0; void BOOST_LOCAL_FUNCTION(bind& x) { void BOOST_LOCAL_FUNCTION(bind& x) { // Nested. x++; } BOOST_LOCAL_FUNCTION_NAME(g) x--; g(); // Nested local function call. } BOOST_LOCAL_FUNCTION_NAME(f) f();
This library never requires to explicitly specify the type of bound variables (e.g., this reduces maintenance because the local function declaration and definition do not have to change even if the bound variable types change as long as the semantics of the local function remain valid). From within local functions, programmers can access the type of a bound variable using the following macro:
BOOST_LOCAL_FUNCTION_TYPEOF(bound-variable-name)
        The BOOST_LOCAL_FUNCTION_TYPEOF
        macro expands to a type expression that evaluates (at compile-time) to the
        fully qualified type of the bound variable with the specified name. This
        type expression is fully qualified in the sense that it will be constant
        if the variable is bound by constant const
        bind[&]
        and it will also be a reference if the variable is bound by reference [const]
        bind&
        (if needed, programmers can remove the const
        and & qualifiers using
        boost::remove_const and boost::remove_reference,
        see Boost.TypeTraits).
      
        The deduced bound type can be used within the body to check concepts, declare
        local variables, etc. For example (see also typeof.cpp
        and addable.hpp):
      
int sum = 0, factor = 10; void BOOST_LOCAL_FUNCTION(const bind factor, bind& sum, int num) { // Type-of for concept checking. BOOST_CONCEPT_ASSERT((Addable<boost::remove_reference< BOOST_LOCAL_FUNCTION_TYPEOF(sum)>::type>)); // Type-of for declarations. boost::remove_reference<BOOST_LOCAL_FUNCTION_TYPEOF( factor)>::type mult = factor * num; sum += mult; } BOOST_LOCAL_FUNCTION_NAME(add) add(6);
        Within templates, BOOST_LOCAL_FUNCTION_TYPEOF
        should not be prefixed by the typename
        keyword but eventual type manipulations need the typename
        prefix as usual (see also typeof_template.cpp
        and addable.hpp):
      
template<typename T> T calculate(const T& factor) { T sum = 0; void BOOST_LOCAL_FUNCTION_TPL(const bind factor, bind& sum, T num) { // Local function `TYPEOF` does not need `typename`. BOOST_CONCEPT_ASSERT((Addable<typename boost::remove_reference< BOOST_LOCAL_FUNCTION_TYPEOF(sum)>::type>)); sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME_TPL(add) add(6); return sum; }
        In this context, it is best to use the BOOST_LOCAL_FUNCTION_TYPEOF
        macro instead of using Boost.Typeof
        to reduce the number of times that Boost.Typeof
        is invoked (either the library already internally used Boost.Typeof
        once, in which case using this macro will not use Boost.Typeof
        again, or the bound variable type is explicitly specified by programmers
        as shown be below, in which case using this macro will not use Boost.Typeof
        at all).
      
        Furthermore, within the local function body it possible to access the result
        type using result_type, the
        type of the first parameter using arg1_type,
        the type of the second parameter using arg2_type,
        etc. [21]
      
        While not required, it is possible to explicitly specify the type of bound
        variables so the library will not internally use Boost.Typeof
        to automatically deduce the types. When specified, the bound variable type
        must follow the bind "keyword"
        and it must be wrapped within round parenthesis ():
      
bind(variable-type) variable-name // Bind by value with explicit type. bind(variable-type)& variable-name // Bind by reference with explicit type. const bind(variable-type) variable-name // Bind by constant value with explicit type. const bind(variable-type)& variable-name // Bind by constant reference with explicit type. bind(class-type*) this_ // Bind object `this` with explicit type. const bind(class-type*) this_ // Bind object `this` by constant with explicit type.
        Note that within the local function body it is always possible to abstract
        the access to the type of a bound variable using BOOST_LOCAL_FUNCTION_TYPEOF
        (even when the bound variable type is explicitly specified in the local function
        declaration).
      
        The library also uses Boost.Typeof
        to determine the local function result type (because this type is specified
        outside the BOOST_LOCAL_FUNCTION
        macro). Thus it is also possible to specify the local function result type
        as one of the BOOST_LOCAL_FUNCTION
        macro parameters prefixing it by return
        so the library will not use Boost.Typeof
        to deduce the result type:
      
BOOST_LOCAL_FUNCTION_TYPE(return result-type, ...)
        Note that the result type must be specified only once either before the macro
        (without the return prefix)
        or as one of the macro parameters (with the return
        prefix). As always, the result type can be void
        to declare a function that returns nothing (so return
        void is allowed when the result type
        is specified as one of the macro parameters).
      
        The following example specifies all bound variables and result types (see
        also add_typed.cpp):
        [22]
      
struct adder { adder(void) : sum_(0) {} int sum(const std::vector<int>& nums, const int& factor = 10) { // Explicitly specify bound variable and return types (no type-of). BOOST_LOCAL_FUNCTION(const bind(const int&) factor, bind(adder*) this_, int num, return int) { return this_->sum_ += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add) std::for_each(nums.begin(), nums.end(), add); return sum_; } private: int sum_; };
Unless necessary, it is recommended to not specify the bound variable and result types. Let the library deduce these types so the local function syntax will be more concise and the local function declaration will not have to change if a bound variable type changes (reducing maintenance).
| ![[Note]](../../../../../doc/src/images/note.png) | Note | 
|---|---|
| When all bound variable and result types are explicitly specified, the library implementation will not use Boost.Typeof. | 
        Local functions can be declared inline
        to increase the chances that the compiler will be able to reduce the run-time
        of the local function call by inlining the generated assembly code. A local
        function is declared inline by prefixing its name with the keyword inline:
      
result-type BOOST_LOCAL_FUNCTION(parameters) { ... // Body. } BOOST_LOCAL_FUNCTION_NAME(inline name) // Inlining.
When inlining a local function, note the following:
boost::function)
            and they cannot be passed as template parameters.
          inline has no
            effect because this library will automatically generate code that uses
            C++11 specific
            features to inline the local function calls whenever possible even if
            the local function is not declared inline. Furthermore, non C++11
            local functions can always be passes as template parameters even when
            they are declared inline. [23]
          | ![[Important]](../../../../../doc/src/images/important.png) | Important | 
|---|---|
| It is recommended to not declare a local function inline unless it is strictly necessary for optimizing pure C++03 compliant code (because in all other cases this library will automatically take advantage of C++11 features to optimize the local function calls while always allowing to pass the local function as a template parameter). | 
        For example, the following local function is declared inline (thus a for-loop
        needs to be used for portability instead of passing the local function as
        a template parameter to the std::for_each
        algorithm, see also add_inline.cpp):
      
int sum = 0, factor = 10; void BOOST_LOCAL_FUNCTION(const bind factor, bind& sum, int num) { sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(inline add) // Inlining. std::vector<int> v(100); std::fill(v.begin(), v.end(), 1); for(size_t i = 0; i < v.size(); ++i) add(v[i]); // Cannot use for_each.
        Local functions can be declared recursive
        so a local function can recursively call itself from its body (as usual with
        C++ functions). A local function is declared recursive by prefixing its name
        with the recursive "keyword"
        (thus recursive cannot be
        used as a local function name):
      
result-type BOOST_LOCAL_FUNCTION(parameters) { ... // Body. } BOOST_LOCAL_FUNCTION_NAME(recursive name) // Recursive.
        For example, the following local function is used to recursively calculate
        the factorials of all the numbers in the specified vector (see also factorial.cpp):
      
struct calculator { std::vector<int> results; void factorials(const std::vector<int>& nums) { int BOOST_LOCAL_FUNCTION(bind this_, int num, bool recursion, default false) { int result = 0; if(num <= 0) result = 1; else result = num * factorial(num - 1, true); // Recursive call. if(!recursion) this_->results.push_back(result); return result; } BOOST_LOCAL_FUNCTION_NAME(recursive factorial) // Recursive. std::for_each(nums.begin(), nums.end(), factorial); } };
Compilers have not been observed to be able to inline recursive local function calls not even when the recursive local function is also declared inline:
... BOOST_LOCAL_FUNCTION_NAME(inline recursive factorial)
Recursive local functions should never be called outside their declaration scope. [24]
| ![[Warning]](../../../../../doc/src/images/warning.png) | Warning | 
|---|---|
| If a local function is returned from the enclosing function and called in a different scope, the behaviour is undefined (and it will likely result in a run-time error). | 
This is not a limitation with respect to C++11 lambda functions because lambdas can never call themselves recursively (in other words, there is no recursive lambda function that can successfully be called outside its declaration scope because there is no recursive lambda function at all).
        Because local functions are functors, it is possible to overload them using
        the boost::overloaded_function functor of Boost.Functional/OverloadedFunction
        from the boost/functional/overloaded_function.hpp header
        (see the Boost.Functional/OverloadedFunction
        documentation for details).
      
        In the following example, the overloaded function object add
        can be called with signatures from either the local function add_s, or the local function add_d, or the local function add_d with its extra default parameter,
        or the function pointer add_i
        (see also overload.cpp):
      
int add_i(int x, int y) { return x + y; }
std::string s = "abc"; std::string BOOST_LOCAL_FUNCTION( const bind& s, const std::string& x) { return s + x; } BOOST_LOCAL_FUNCTION_NAME(add_s) double d = 1.23; double BOOST_LOCAL_FUNCTION(const bind d, double x, double y, default 0) { return d + x + y; } BOOST_LOCAL_FUNCTION_NAME(add_d) boost::overloaded_function< std::string (const std::string&) , double (double) , double (double, double) // Overload giving default param. , int (int, int) > add(add_s, add_d, add_d, add_i); // Overloaded function object. BOOST_TEST(add("xyz") == "abcxyz"); // Call `add_s`. BOOST_TEST((4.44 - add(3.21)) <= 0.001); // Call `add_d` (no default). BOOST_TEST((44.44 - add(3.21, 40.0)) <= 0.001); // Call `add_d`. BOOST_TEST(add(1, 2) == 3); // Call `add_i`.
        It is possible to program exception specifications for local functions by
        specifying them after the BOOST_LOCAL_FUNCTION
        macro and before the body code block {
        ... }.
      
| ![[Important]](../../../../../doc/src/images/important.png) | Important | 
|---|---|
| 
          Note that the exception specifications only apply to the body code specified
          by programmers and they do not apply to the rest of the code automatically
          generated by the macro expansions to implement local functions. For example,
          even if the body code is specified to throw no exception using  | 
        For example (see also add_except.cpp):
      
double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION(const bind factor, bind& sum, double num) throw() { // Throw nothing. sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add) add(100);
        Local function parameters support the storage classifiers as usual in C++03.
        The auto storage classifier
        is specified as: [25]
      
auto parameter-type parameter-name
        The register storage classifier
        is specified as:
      
register parameter-type parameter-name
        For example (see also add_classifiers.cpp):
      
int BOOST_LOCAL_FUNCTION(auto int x, register int y) { // Classifiers. return x + y; } BOOST_LOCAL_FUNCTION_NAME(add)
        In general, it is not possible to expand the BOOST_LOCAL_FUNCTION,
        BOOST_LOCAL_FUNCTION_TPL
        macros multiple times on the same line. [26]
      
        Therefore, this library provides additional macros BOOST_LOCAL_FUNCTION_ID
        and BOOST_LOCAL_FUNCTION_ID_TPL
        which can be expanded multiple times on the same line as long as programmers
        specify unique identifiers as the macros' first parameters. The unique identifier
        can be any token (not just numeric) that can be successfully concatenated
        by the preprocessor (e.g., local_function_number_1_at_line_123).
        [27]
      
        The BOOST_LOCAL_FUNCTION_ID
        and BOOST_LOCAL_FUNCTION_ID_TPL
        macros accept local function parameter declaration lists using the exact
        same syntax as BOOST_LOCAL_FUNCTION.
        For example (see also same_line.cpp):
      
#define LOCAL_INC_DEC(offset) \ int BOOST_LOCAL_FUNCTION_ID(BOOST_PP_CAT(inc, __LINE__), /* unique ID */ \ const bind offset, const int x) { \ return x + offset; \ } BOOST_LOCAL_FUNCTION_NAME(inc) \ \ int BOOST_LOCAL_FUNCTION_ID(BOOST_PP_CAT(dec, __LINE__), \ const bind offset, const int x) { \ return x - offset; \ } BOOST_LOCAL_FUNCTION_NAME(dec) #define LOCAL_INC_DEC_TPL(offset) \ T BOOST_LOCAL_FUNCTION_ID_TPL(BOOST_PP_CAT(inc, __LINE__), \ const bind offset, const T x) { \ return x + offset; \ } BOOST_LOCAL_FUNCTION_NAME_TPL(inc) \ \ T BOOST_LOCAL_FUNCTION_ID_TPL(BOOST_PP_CAT(dec, __LINE__), \ const bind offset, const T x) { \ return x - offset; \ } BOOST_LOCAL_FUNCTION_NAME_TPL(dec) template<typename T> void f(T& delta) { LOCAL_INC_DEC_TPL(delta) // Multiple local functions on same line. BOOST_TEST(dec(inc(123)) == 123); } int main(void) { int delta = 10; LOCAL_INC_DEC(delta) // Multiple local functions on same line. BOOST_TEST(dec(inc(123)) == 123); f(delta); return boost::report_errors(); }
        As shown by the example above, the BOOST_LOCAL_FUNCTION_ID
        and BOOST_LOCAL_FUNCTION_ID_TPL
        macros are especially useful when it is necessary to invoke them multiple
        times within a user-defined macro (because the preprocessor expands all nested
        macros on the same line).
      
The following table summarizes all C++ function features indicating those features that are not supported by this library for local functions.
| C++ Function Feature | Local Function Support | Comment | 
|---|---|---|
| 
                   | No. | 
                  This is not supported because local functions cannot be templates
                  (plus most C++ compilers do not implement  | 
| 
                   | No. | This is not supported because local functions are implemented using local classes and C++03 local classes cannot be templates. | 
| 
                   | No. | This is not supported because local functions are not constructors. | 
| 
                   | Yes. | 
                  Local functions can be specified  | 
| 
                   | No. | This is not supported because local functions are always defined locally within the enclosing scope and together with their declarations. | 
| 
                   | No. | This is not supported because local functions are not member functions. | 
| 
                   | No. | This is not supported because local functions are not member functions. [a] | 
| 
                   | Yes. | This is supported (see the Tutorial section). | 
| 
                   | Yes. | Local functions are named and they can call themselves recursively but they cannot be operators (see the Tutorial and Advanced Topics sections). | 
| 
                   | Yes. | 
                  This is supported and it also supports the  | 
| 
                  Trailing  | No. | This is not supported because local functions are not member functions. | 
| 
                  Trailing  | No. | This is not supported because local functions are not member functions. | 
| [a] Rationale. It would be possible to make a local function class inherit from another local function class. However, this "inheritance" feature is not implemented because it seemed of no use given that local functions can be bound to one another thus they can simply call each other directly without recurring to dynamic binding or base function calls. | ||
        Local functions cannot be operators. Naming a local function operator...
        will generate a compile-time error. [28]
      
        For example, the following code does not compile (see also operator_error.cpp):
      
bool BOOST_LOCAL_FUNCTION(const point& p, const point& q) { return p.x == q.x && p.y == q.y; } BOOST_LOCAL_FUNCTION_NAME(operator==) // Error: Cannot use `operator...`.
        It is possible to jump with a goto
        within the local function body. For example, the following compiles (see
        also goto.cpp):
      
int error(int x, int y) { int BOOST_LOCAL_FUNCTION(int z) { if(z > 0) goto success; // OK: Can jump within local function. return -1; success: return 0; } BOOST_LOCAL_FUNCTION_NAME(validate) return validate(x + y); }
        However, it is not possible to jump with a goto
        from within the local function body to to a label defined in the enclosing
        scope. For example, the following does not compile (see also goto_error.cpp):
      
int error(int x, int y) { int BOOST_LOCAL_FUNCTION(int z) { if(z <= 0) goto failure; // Error: Cannot jump to enclosing scope. else goto success; // OK: Can jump within local function. success: return 0; } BOOST_LOCAL_FUNCTION_NAME(validate) return validate(x + y); failure: return -1; }
[17] 
          Rationale. The assignment symbol = cannot be used to specify default parameter
          values because default values are not part of the parameter type so they
          cannot be handled using template meta-programming. Default parameter values
          need to be separated from the rest of the parameter declaration using the
          preprocessor. Specifically, this library needs to use preprocessor meta-programming
          to remove default values when constructing the local function type and
          also to count the number of default values to provide the correct set of
          call operators for the local functor. Therefore, the symbol = cannot be used because it cannot be handled
          by preprocessor meta-programming (non-alphanumeric symbols cannot be detected
          by preprocessor meta-programming because they cannot be concatenated by
          the preprocessor).
        
[18] 
          The authors do not personally find the use of the WITH_DEFAULT
          macro more readable and they prefer to use the default
          keyword directly. Furthermore, WITH_DEFAULT
          needs to be defined differently for compilers without variadic macros
          #define WITH_DEFAULT
          (default) so it can only be defined by programmers
          based on the syntax they decide to use (see the No
          Variadic Macros section).
        
[19] 
          Rationale. This limitation is because
          this library uses preprocessor token concatenation ##
          to inspect the macro parameters (to distinguish between function parameters,
          bound variables, etc) and the C++ preprocessor does not allow to concatenate
          non-alphanumeric tokens.
        
[20] 
          The preprocessor always interprets unwrapped commas as separating macro
          parameters. Thus in this case the comma will indicate to the preprocessor
          that the first macro parameter is const
          std::map<std::tring, the second macro parameter is
          size_t>&
          m, etc instead of passing const std::map<std::string, size_t>& m
          as a single macro parameter.
        
[21] 
          Rationale. The type names result_type and argN_type follow the Boost.TypeTraits
          naming conventions for function traits.
        
[22] In the examples of this documentation, bound variables, function parameters, and the result type are specified in this order because this is the order used by C++11 lambda functions. However, the library accepts bound variables, function parameters, and the result type in any order.
[23] 
              Rationale. This library uses an indirect
              function call via a function pointer in order to pass the local function
              as a template parameter (see the Implementation
              section). No compiler has yet been observed to be able to inline function
              calls when they use such indirect function pointer calls. Therefore,
              inline local functions do not use such indirect function pointer call
              (so they are more likely to be optimized) but because of that they
              cannot be passed as template parameters. The indirect function pointer
              call is needed on C++03
              but it is not needed on C++11
              (see [N2657]
              and Boost.Config's
              BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS)
              thus this library automatically generates local function calls that
              can be inline on C++11
              compilers (even when the local function is not declared inline).
            
[24] 
          Rationale. This limitation comes from
          the fact that the global functor used to pass the local function as a template
          parameter (and eventually returned outside the declarations scope) does
          not know the local function name so the local function name used for recursive
          call cannot be set in the global functor. This limitation together with
          preventing the possibility for inlining are the reasons why local functions
          are not recursive unless programmers explicitly declare them recursive.
        
[25] 
          The auto storage classifier
          is part of the C++03
          standard and therefore supported by this library. However, the meaning
          and usage of the auto keyword
          changed in C++11.
          Therefore, use the auto storage
          classifier with the usual care in order to avoid writing C++03
          code that might not work on C++11.
        
[26] 
          Rationale. The BOOST_LOCAL_FUNCTION
          and BOOST_LOCAL_FUNCTION_TPL
          macros internally use __LINE__
          to generate unique identifiers. Therefore, if these macros are expanded
          more than on time on the same line, the generated identifiers will no longer
          be unique and the code will not compile. (This restriction does not apply
          to MSVC and other compilers that provide the non-standard __COUNTER__ macro.) Note that the BOOST_LOCAL_FUNCTION_NAME macro
          can always be expanded multiple times on the same line because the unique
          local function name (and not __LINE__)
          is used by this macro to generate unique identifiers (so there is no need
          for a BOOST_LOCAL_FUNCTION_NAME_ID
          macro).
        
[27] Because there are restrictions on the set of tokens that the preprocessor can concatenate and because not all compilers correctly implement these restrictions, it is in general recommended to specify unique identifiers as a combination of alphanumeric tokens.
[28] Rationale. This is the because a local function name must be a valid local variable name (the local variable used to hold the local functor) and operators cannot be used as local variable names.