Re: [boost] VC7.1 ICE

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-03-01 17:16:53

Peder Holt wrote:
> Tobias Schwinger wrote:
>>Unfortunately the same trick won't help to get rid of the ICE in 
>>rule_parser_2_2 when applied to the subscript operator of 
>>spirit::parser (would've been too easy)...
> 
> 
> I have looked at this, and this is a problem between VC7.1 and the way
> the typeof emulation works, as you showed in the simplified test-case.
> The problem lies in the use of the operator[] with function pointers.
> 
> The only workaround for this problem that I have found, apart from
> rewriting the user code, is to separate the sizeof operation and the
> typedef.
> (like in the #if ! defined BOOM clause)
> Problem is, this has to be done inside a struct, and can not be made
> to emulate the BOOST_TYPEOF syntax.
> The proposed solution is then to add a new macro called something like:
> BOOST_TYPEOF_NESTED_TYPEDEF(name,expr) which looks roughly like this:
> struct name {
>    //Twophase typeof using expr
>    typedef resulting_type_calculated type;
> };
> 
> To access the type, you have to do a typedef typename name::type
> my_type; outside BOOST_TYPEOF_NESTED_TYPEDEF.
> 
> Introducing this construct has two positive effects:
> 1. rule_parser_2_2 (and similar tests) pass.
> 2. In emulation mode, there is no longer any limit to the complexity
> of the types passed to BOOST_TYPEOF_NESTED_TYPEDEF.
> BOOST_TYPEOF_LIMIT_SIZE is no longer a limiting factor.

Wow! Sounds like a pretty cool workaround to me.

Will the proposed interface allow me to inject static variables into the context the expression is evaluated in?

Clarification:

Using a SPIRIT_RULE_PARSER with the expression

   p >> *(d >> p)

, p and d being templated parameters, the macro generates 

   // ...
   struct __parser
   {
       // Injected names
       // (these are member variables in the "runtime version" of the
       // expression which is assigned to a member variable of type 
       // __parser::type)
       static P0 & p;         
       static P1 & d; 

       typedef typeof(  p >> *(d >> p)  ) type;
   };
   // ...

Wouldn't I have to declare p and d inside the nested struct in this case?

> The downside is the added complexity of the library. 

> It also doesn't reflect any proposed C++ features.

So what? It's closer to the semantics of native typeof because the limits aren't so tight and because it's stable.

It would be interesting to know whether it also eliminates the ADL failure and the weird "deduction from base fails for non-overloaded functions" bug in VC8 [ see http://tinyurl.com/7j9me ] ...

> Is there any interest in adding this feature to the typeof library?

YES!

It also seems very well-suited for planned Spirit-2

   http://spirit.sourceforge.net/dl_docs/redesigning_spirit.html

as we'll easily hit the current limits trying to handle the results of the proposed kind of parser-transformation, I figure. 
In fact, I was tempted to make "subexpression registration" [ discussed with Arakdiy here: http://tinyurl.com/asnxq ], which can significantly reduce the required TYPEOF_LIMIT_SIZE, an official feature request for Typeof after reading that document.

Thanks again -you da man- ;-),

Tobias