Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
Hello, About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it. I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review. I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... : Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/ Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places? Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice. Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... : Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable. Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-) (8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... : Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros? [quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... : Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN... Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now. 2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com>
Please state clearly whether you think this library should be accepted as a Boost library.
Yes. Other questions you may want to consider:
- What is your evaluation of the design?
I like it.
- What is your evaluation of the documentation?
I enjoyed reading it, and I think it gave me a pretty good idea about the library.
- What is your evaluation of the implementation?
From what I read in the Implementation section of the docs, looks reasonable.
- What is your evaluation of the potential usefulness of the library?
I can imagine it would improve readability of some of my code.
- Did you try to use the library? With what compiler? Did you have any problems?
No. I intend to, but not until the end of this review.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
In-depth study of the docs.
- Are you knowledgeable about the problem domain?
Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming. Please also consider the following issues and proposals specific to
Boost.Local. Your opinion is welcome on any or all of these.
- Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how?
I haven't used ScopeExit, so I don't have an opinion on this. - Lorenzo is proposing to add boost::local::function::overload to
Boost.Function as boost::function::overload. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loca...
I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template?
- Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN... - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN...
I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed. Thanks in advance to all who participate in the review discussion; I'm
looking forward to it!
- Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)
This was my first review, and I hope it's useful ;-) Regards, Kris
On Sat, Nov 12, 2011 at 12:59 PM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
Hello,
Hello Kris and thank you very much for your review!
About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it.
I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review.
I have only compiled Boost.Local examples with GCC and MSVC. If the library is accepted, a larger set of compilers will be tested. Please let me know how it goes with your compilers even if that's after the review's end.
I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... :
Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/
OK.
Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places?
Yes, it should be possible to use this_ in both the local function declaration and definition. This might be a good idea because if you bind this instead of this_ in the local function declaration I can generate a descriptive compile-time error. I am also thinking to use _this instead of this_ to be consistent with Boost.Phoenix placeholder naming convention (especially if _this is also used in declaration, it will really act as a placeholder). Does anyone else have an opinion? What is most readable?
Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice.
Local blocks are "better" than ordinary C++ blocks because the local block code has restricted access to just the variables that you bind so you don't mess up by mistake variables you are not supposed to touch within the local block. In addition, constant binding can be used to make an enclosing variable constant just within the local block (again, limiting your ability to mess up these variables even when you need to read them within the local block). For example, this is very handy if you want to assert the value of a variable while making sure that you don't change such a value by mistake. You bind the variable by const& and put the assertion in the local block so the assertion is "constant-correct" (BTW, this was the original use case that motivated me to write Boost.Local). For example, say there is a bug for which we type i = 1 instead of i == 1 in the assertions below: int i = 0; assert(i = 1); // will pass :( BOOST_LOCAL_BLOCK(const bind i) { assert(i = 1); // will fail at compile time :) } Clearly the assertion within the local block is superior because it will catch the bug at compile-time (while the other assertion will not even error at run-time). This is because using local blocks we can program the semantic "this assertion instruction is not supposed to change the value of i". This stated in the footnote: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... And the implied in: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... I will make this comparison between local and normal blocks more clear in the Tutorial section.
Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed?
Only 4b will print "hello" because: 1) 4a terminates with an uncaught exception. 2) 4c throws and quits (but not by uncaught exception) and before declaring the local exit. 3) Instead, 4b quits (but not by uncaught exception) only after declaring the local exit. This is the exact same behavior of Boost.ScopeExit. I can explain this better in the docs, in fact I can add your examples above and comment on which one prints or not "hello" and why.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... :
Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable.
Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if
OK.
Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-)
OK, I'll try to simplify the text (maybe using a table...).
(8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface?
Yes, I can see what can be considered a requirement of the interface and move that up front in the Tutorial or Advanced Topics sections.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... :
Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause?
Same as above, I'll consider and add this.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... :
Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros?
This is saying that the default definition of this macro as provided by Boost.Local is #undef. If the user does not #define this macro, the library will leave this macro #undefined. (Note this is not the case for other CONFIG macros which are #defined by the library when not #defined by the user, for example if the user does not define CONFIG_FUNCTION_ARITY_MAX then Boost.Local #defines CONFIG_FUNCTION_ARITY_MAX to be 5.) I can clarify this in the text.
[quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful.
OK.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... :
Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... :
Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well.
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOCA... : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here.
Yes, typename is not required (see Advanced Topics section). I will repeat that information in the Reference section. I will also add reasons (currently not in the docs) of why BOOST_LOCAL_TYPEOF(x) should be used instead of BOOST_TYPEOF(x): 1) The user can optionally specify the type of the bound variables `bind(int) x` in which case BOOST_LOCAL_TYPEOF(x) access the bound variable type `int` without using Boost.Typeof. 2) The BOOST_LOCAL_TYPEOF(x) type retains the eventual const qualifier when the variable is bound by constant `const bind x` while BOOST_TYPEOF(x) does not. int x = 1; BOOST_LOCAL_BLOCK(const bind(int) x) { BOOST_LOCAL_TYPEOF(x) y = x + 10; // type is `const int` plus don't use Boost.Typeof BOOST_TYPEOF(x) z = y; // type is `int` without const }
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN... Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known
OK.
This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now.
2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung@gmail.com>
Please state clearly whether you think this library should be accepted as a Boost library.
Yes.
:)
Other questions you may want to consider:
- What is your evaluation of the design?
I like it.
- What is your evaluation of the documentation?
I enjoyed reading it, and I think it gave me a pretty good idea about the library.
- What is your evaluation of the implementation?
From what I read in the Implementation section of the docs, looks reasonable.
- What is your evaluation of the potential usefulness of the library?
I can imagine it would improve readability of some of my code.
- Did you try to use the library? With what compiler? Did you have any problems?
No. I intend to, but not until the end of this review.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
In-depth study of the docs.
- Are you knowledgeable about the problem domain?
Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming.
Please also consider the following issues and proposals specific to
Boost.Local. Your opinion is welcome on any or all of these.
- Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how?
I haven't used ScopeExit, so I don't have an opinion on this.
- Lorenzo is proposing to add boost::local::function::overload to
Boost.Function as boost::function::overload. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loca...
I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template?
overload _could_ be added as an inner class of function... but the main question here is if overload should be part of Boost.Function instead of Boost.Local because overhead works with any functor (not just local functors)-- question to which you answered "yes, it seems reasonable". If at the end overload should go in Boost.Function and it cannot be named function::overload, it'll be named something else.
- Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN... - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN...
I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed.
Thanks in advance to all who participate in the review discussion; I'm
looking forward to it!
- Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)
This was my first review, and I hope it's useful ;-)
Very useful! Thanks a lot! --Lorenzo
2011/11/13 Lorenzo Caminiti <lorcaminiti@gmail.com>
On Sat, Nov 12, 2011 at 12:59 PM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
[snip]
I have only compiled Boost.Local examples with GCC and MSVC. If the library is accepted, a larger set of compilers will be tested. Please let me know how it goes with your compilers even if that's after the review's end.
Sure, I'll be hapy to ;-) [snip]
Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice.
Local blocks are "better" than ordinary C++ blocks because the local block code has restricted access to just the variables that you bind so you don't mess up by mistake variables you are not supposed to touch within the local block. In addition, constant binding can be used to make an enclosing variable constant just within the local block (again, limiting your ability to mess up these variables even when you need to read them within the local block).
For example, this is very handy if you want to assert the value of a variable while making sure that you don't change such a value by mistake. You bind the variable by const& and put the assertion in the local block so the assertion is "constant-correct" (BTW, this was the original use case that motivated me to write Boost.Local). For example, say there is a bug for which we type i = 1 instead of i == 1 in the assertions below:
int i = 0; assert(i = 1); // will pass :( BOOST_LOCAL_BLOCK(const bind i) { assert(i = 1); // will fail at compile time :) }
Clearly the assertion within the local block is superior because it will catch the bug at compile-time (while the other assertion will not even error at run-time). This is because using local blocks we can program the semantic "this assertion instruction is not supposed to change the value of i".
This stated in the footnote:
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca... And the implied in:
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca...
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca...
I will make this comparison between local and normal blocks more clear in the Tutorial section.
Thanks. I think it will be nice for a person reading the tutorial to see clearly the advantage of Local Blocks over normal blocks. [snip]
Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed?
Only 4b will print "hello" because: 1) 4a terminates with an uncaught exception. 2) 4c throws and quits (but not by uncaught exception) and before declaring the local exit. 3) Instead, 4b quits (but not by uncaught exception) only after declaring the local exit.
This is the exact same behavior of Boost.ScopeExit. I can explain this better in the docs, in fact I can add your examples above and comment on which one prints or not "hello" and why.
Great ;-) [snip]
- Lorenzo is proposing to add boost::local::function::overload to
Boost.Function as boost::function::overload. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loca...
I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template?
overload _could_ be added as an inner class of function...
I desagree. I think it's reasonable for overload to be part of Boost.Function, but not part of the class boost::function. It definitely should be a separate class.
but the main question here is if overload should be part of Boost.Function instead of Boost.Local because overhead works with any functor (not just local functors)-- question to which you answered "yes, it seems reasonable".
Correct.
If at the end overload should go in Boost.Function and it cannot be named function::overload, it'll be named something else.
OK. Regards, Kris
Firstly, thanks, Krzysztof for your review of the documentation and design! On Sat, Nov 12, 2011 at 9:59 AM, Krzysztof Czainski <1czajnik@gmail.com>wrote:
Hello,
About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it.
I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review.
[...] If this is something you would be able to do by the end of *next* week, I would have no trouble formally or informally extending the review to give you a chance to try out the library on a real project. I think such experience would prove valuable.
- Lorenzo is proposing to add boost::local::function::overload to
Boost.Function as boost::function::overload. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loca...
I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template?
Ack, of course. The question really is: Is boost::local::function::overload of sufficient general interest to give it a more natural home?
- Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN...
- Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDEN...
I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed.
Noted.
Thanks in advance to all who participate in the review discussion; I'm
looking forward to it!
- Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)
This was my first review, and I hope it's useful ;-)
Indeed, and thanks again! - Jeff
participants (3)
-
Jeffrey Lee Hellrung, Jr. -
Krzysztof Czainski -
Lorenzo Caminiti