Re: [boost] Rave for proposed Boost.Local (functions)

Subject: Re: [boost] Rave for proposed Boost.Local (functions)
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-02-07 11:42:13

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