Boost logo

Boost :

Subject: Re: [boost] [local] local functions ready for review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-01-04 08:24:47


On 1/3/2011 10:04 PM, Lorenzo Caminiti wrote:
> On Mon, Jan 3, 2011 at 12:58 PM, Edward Diener<eldiener_at_[hidden]> wrote:
>> On 1/3/2011 12:22 PM, Lorenzo Caminiti wrote:
>>>
>>> Hello all,
>>>
>>> A few months ago, I probed for interest in a library for local
>>> functions with Boost.ScopeExit's variable binding. Based on that
>>> discussion, I have now implemented the Boost.Local library.
>>>
>>> I have uploaded the source files boost-local_0_1_0-818.zip in the
>>> Boost Vault under Function Objects:
>>>
>>> http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Function%20Objects
>>>
>>> The documentation on the web:
>>>
>>> http://contractpp.sourceforge.net/boost-local_0_1_0-818/libs/local/doc/html/index.html
>>>
>>> Any comment?
>>
>> I can understand the potential usefulness of local functions and local
>> exits, but it seems local blocks serve little purpose, other than an easier
>> syntactical notice, because it is a macro, over a simple block using { }
>> which can also of course access variables in the enclosing scope. I do see
>> where one can bind variables in local blocks in a few ways but that seems to
>> offer little over just normal C++ blocks.
>
> It's funny that local blocks were actually the main use case that
> motivated me in developing the library... My use case for local blocks
> was to check assertion in a constant-correct context (this is also
> explained in the Boost.Local documentation). Consider the following:
>
> void zero(int& x) {
> x = 0;
> assert(x == 0);
> }
>
> If I mistake operator== with operator= I will get a run-time error as
> the assertion will fail. However, ideally such a mistake would be
> caught at compile-time if I could also program the semantic constraint
> that assertions should not change the state of the program (but only
> check the state of the program). So I would like to use a
> "const-block" (borrowing the syntax from
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1613.pdf
> bottom of page 15):
>
> void zero(int& x) {
> x = 0;
> const {
> assert(x == 0);
> }
> }
>
> Unfortunately, this is not valid C++ syntax :( but Boost.Local
> const-binding can be used instead:
>
> void zero(int& x) {
> x = 0;
> BOOST_LOCAL_BLOCK( (const bind)((&x)) ) {
> assert(x == 0);
> } BOOST_LOCAL_BLOCK_END
> }
>
> Now if I mistake operator== with operator= I get a compile-time error :)
>
> This was the original use case that motivated me in developing
> Boost.Local and I still think this is a good use case that shows how
> local blocks can be useful. However, I agree that local functions are
> by far the main feature of this library. (In fact, both local exits
> and blocks essentially comes for free as they are implemented as local
> functions with no parameter and not result type.)
>

There is nothing wrong with formalizing access to variables within
blocks, which is what your local blocks appear to do. I think though
that most programmers may find it unnecessary. OTOH your local functions
and your extension of scope exit is more useful.

>> Nonetheless your library seems interesting. Would you consider putting it in
>> the sandbox also ( or instead ) ? That way, when and if you need to update
>> it, others can pick up the updates via SVN.
>
> Yes, I am happy to upload the library in SVN. How do I do this? (I do
> not have write access to Boost SVN...)

I think you just have to ask for write access to the sandbox in a
message on this NG. I recall that is what I did. The advantage of a
sandbox library is that you create the structure of your library in such
a way that it becomes much easier both to update it and for others to
pick up the updates.

>
>>> As far as I can tell, Boost.Local is ready for a formal review so I am
>>> looking for a review manager. Any volunteer?
>>
>> I can understand your being eager for a review, but shouldn't you let
>> interested parties use it first for a short period of time ?
>
> Of course: Boosters please play with Boost.Local and let me know what
> you think! The source is in the Boost Vault and there are quite a few
> examples with the source plus a few more within the documentation
> text.
>
> I much rather have the opportunity to improve the library before a
> review than having the library fail the review miserably :)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk