
AMDG On 2/7/2011 12:42 AM, Jeffrey Lee Hellrung, Jr. wrote:
At the risk of being off-topic, I strongly feel compelled to ask some follow-up questions...
As I understand it, the first occurrence within a given scope is parsed as
boost::scope_exit::aux::declared< boost::scope_exit::aux::resolve< sizeof( boost_local_auxXargs )
::cmp1< 0 >::cmp2 boost_local_auxXargs;
which is a declaration of a variable called boost_local_auxXargs in local scope which *hides* the variable of the same name from the global scope. Thus all subsequent references to boost_local_auxXargs in this scope refer to this variable. But I don't really understand how the extern global declaration ties into this, except...it gives sizeof( boost_local_auxXargs ) meaning...?
The first time through, sizeof(boost_local_auxXargs) refers to the global. Afterward, it refers to a local variable. The two types are designed to have different sizes. resolve is specialized to trigger the correct parse. resolve<>::cmp1 is a template the first time and an int subsequently.
Why is the extern keyword necessary in the global declaration? Wouldn't something like
const boost::scope_exit::aux::undeclared boost_local_auxXargs = { };
(at global scope) suffice?
It would, but extern avoids actually creating the variable. It's only used in sizeof, so it doesn't actually have to exist.
<snip>
Looking back at the macro expansion Lorenzo supplied, it seems the only use for this boost_local_auxXargs variable is to hold a definite reference to the bound variables struct to be used within BOOST_LOCAL_FUNCTION_END( xxx ). I can see the necessity of this for BOOST_SCOPE_EXIT_END, but BOOST_LOCAL_FUNCTION_END has the name of the local function passed to it, which should be unique to the scope, hence could be used to construct a unique name for the reference to the bound variables struct. So it seems this "awful hack" wouldn't be necessary for (proposed) Boost.Local. Am I missing something?
You're not missing anything. The hack was only introduced to avoid having to use a name in scope_exit, like in Boost.Local.
Again, apologies if this is too off-topic, but Steven's explanation really put a "WTF" look on my face (directed toward this "awful hack", not Steven).
In Christ, Steven Watanabe