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