Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński

Subject: Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2011-11-12 20:05:19

2011/11/13 Lorenzo Caminiti <lorcaminiti_at_[hidden]>

> On Sat, Nov 12, 2011 at 12:59 PM, Krzysztof Czainski <1czajnik_at_[hidden]>
> 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_local/Tutorial.html#ftn.boost_local.Tutorial.Binding.f3
> And the implied in:
>
> https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Tutorial.html#boost_local.Tutorial.local_blocks
>
> https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html#boost_local.Alternatives.local_blocks
>
> 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/local/function/overload.html
> >
> >
> > 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