Subject: Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-25 15:20:59
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
>>>> 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.
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk