Re: [boost] [local_function] how bad is this `static_cast<>`?

Subject: Re: [boost] [local_function] how bad is this `static_cast<>`?
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-09-11 14:52:06

On Thu, Sep 9, 2010 at 12:13 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> AMDG
>
> Lorenzo Caminiti wrote:
>>
>> How bad is the `static_cast<>` below?
>>
>> struct c {
>>    void g() {}
>>
>>    void f() {
>>        struct l: c { // Local function class wrapper.
>>            void body() {
>>                g(); // Usual implicit `this` access.
>>                this->g(); // Usual explicit `this` access.
>>            }
>>        };
>>
>>        static_cast<l*>(this)->body(); // *** HOW BAD IS THIS
>> `STATIC_CAST<>`? ***
>>    }
>> };
>>
>> Could Boost.LocalFunction internally use such a technique when a
>> special configuration macro is #defined by the users?
>>
>> IMO, if this `static_cast<>` can really corrupt memory on some
>> systems/compilers, maybe Boost.LocalFunction should *never* use it.
>> Otherwise, what would the documentation say "WARNING: If you #define
>> this configuration macro, memory could be corrupted in some unknown
>> way on some unknown combination of systems/compilers..." -- it's like
>> providing a self-destruction button with a random countdown sequence
>> via the configuration macro! What do you think?
>>
>
> The problem with code like this is that it can cause the optimizer
> to make incorrect assumptions and miscompile the code.  I
> believe that this has been observed with gcc.

Does this means Booster will NOT accept such a code/hack?

Please express the Boost community option about:
1) Is this code/hack acceptable if guarded by a CONFIG macro?
2) Is the syntax that require explicit use of the special name `this_`
inside a local function acceptable?

Supporting this hack (even when wrapped by the CONFIG macro) is
starting to pose some serious implementation issues for
Boost.LocalFunction (these have to do with allowing recursive local
function calls, supporting `auto bound`, etc essentially because the
`static_cast<>` will miserably fail if the class has member
variables). This is an implementation hack so no wonder it's causing
more and more issues... There could be ways around these issues but I
need to know if the hack will eventually be accepted before I spend
time investigating workarounds.

I almost wish Boosters could conclude they will not want/accept the
hack and they are willing to use `this_` so to make
Boost.LocalFunction implementation easier :) .

*** Please advice -- or ask questions if you need more information in
order to advice. ***

Thank you.

--
Lorenzo