On Fri, Nov 25, 2011 at 3:20 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 25/11/11 20:39, Lorenzo Caminiti a écrit :
On Fri, Nov 25, 2011 at 2:17 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> 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@wanadoo.fr> 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