Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?

Subject: Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-25 16:05:42

On Fri, Nov 25, 2011 at 3:20 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Le 25/11/11 20:39, Lorenzo Caminiti a écrit :
>>
>> On Fri, Nov 25, 2011 at 2:17 PM, Thomas Klimpel
>> <Thomas.Klimpel_at_[hidden]>  wrote:
>>>
>>> Mathias Gaunard wrote:
>>>>>
>>>>> DISCLAIMER: I apologize in advance if there's a way to do access priv
>>>>> and prot from the Phoenix global functor which I was not able to
>>>>
>>>> find.
>>>>>
>>>>> I'm sure Phoenix experts will be able to correct my example if such a
>>>>> possibility exists :)
>>>>
>>>> It's not possible with Phoenix, though I believe there are hacks to
>>>> make it possible somewhat.
>>>
>>> I guess I would create a static member function and adapt it with
>>> Phoenix. Is this one of the hacks you imagined? Or were you more thinking in
>>> the direction of "friend" declarations?
>>
>> Yes, friendship will work as in the example below. However, please
>> note that now the functor is not only non-local but it also has to
>> explicitly override the class access level being declared as friend.
>> In addition please also note that in order to declare the friendship
>> you have to explicitly specify the bound type `int` (and you'll have
>> to change the friendship declaration if you change the type of the
>> bound variable a declared locally within the function).
>>
> You are right, if you use a global function, but in this case I think the
> best is to use a private function so that you have automatic access to all
> the members.
>
> I have a question Lorenzo, how do you reach to have access to the non-public
> members from the local function? Forget me if this is already explained in
> the documentation, just please, point where.

It's not in the docs :( AFAIU, it's because of the fix to C++03 defect
#45 which made types declared within a class (inner, local, etc) see
all members of the outer class as if they were automatically friends:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45

So this works:

#include <iostream>

struct x {
    void f() {
        struct local {
            static void func() {
                priv();
                prot();
                publ();
            }
        };
        local::func();
    }
public:
    static void publ() { std::cout << "public" << std::endl; }
protected:
    static void prot() { std::cout << "protected" << std::endl; }
private:
    static void priv() { std::cout << "private" << std::endl; }
};

int main ( ) {
    x xx;
    xx.f();
    return 0;
}

That's my understanding.

(Probably irrelevant here, but I investigated this issue 3+ years ago
because if they didn't fix this defect (which they did) I'd have been
able to prevent contract assertions to use non-public members which is
what Eiffel, but N1962 does not prevent such an access so at the end
this is a Contract Programming requirement up for "interpretation".)

>> That's to Vicente 2nd feature. To Vicente 1st feature instead:
>>
>> On Fri, Nov 25, 2011 at 11:06 AM, Vicente Botet
>> <vicente.botet_at_[hidden]>  wrote:
>>>
>>> I think that most of us would admit that local functions are useful, but
>>> as
>>> discussed during the review, Boost.Local doesn't provides local
>>> functions.
>>> The missing features been:
>>> * implicit access to the accessible variables
>>
>> Please note that while it is true that with Boost.Local you have to
>> explicitly say `bind this` (as in the local function declaration) with
>> the Phoenix example you still have to explicitly say `this` (and in
>> the call `globalf(this)();`). So in a sense both approaches fail to
>> provide "implicit access to the accessible variables"... Did I
>> understand the meaning of Vicente's 1st feature correctly?
>>
> My concer was respect to local functions intergrated in the language, from
> which I would expect that we don't need to pass this a parameter and have
> direct access to all the functions and data accessible from the embedding
> function.

Makes sense (even if C++11 chosen not automatically bind the entire
environment, that said they do provide the [&] which is a very short
way to bind the entire environment).

Thanks.
--Lorenzo