Re: [Cpptool-develop] Declaration parsing started...

[Andre B. <and...@gm...>]

Baptiste Lepilleur wrote:

>>I'll try to replace the variable-
>>declaration-mutator as soon as the 'variable-detection' is handled by
>>the new Parser.
>>    
>>
>
>Local variable declaration is very close to class attribute declaration, so
>reuse should occur.
>
Definitly, however the declaration list within a class body has an 
extended syntax (visibility keywords and
pure-declaration. But I think we can simply extend the usual 
declaration-list-parser for this, since these
keywords will not appear at filescope.

>>Durring tests I also recognized a problem in parsing declaration which
>>can not be solved with parser
>>information only (I believe): (Has been added to the Wiki)
>>
>>      typedef int myint;
>>
>>      class x {
>>      public:
>>         static myint y;
>>      };
>>
>>      myint ::x::y;        // <--- how to parse ?
>>(variant a)  type "myint::x::y"  + no variable
>>(variant b)  type "myint::x"     + variable "::y"
>>(variant c)  type "myint"        + variable "::x::y"
>>
>>      btw: spaces are allowed between '::' and identifier ("x<space>::y"
>>equals "x::y")
>>      "class x ::z::y" has three meanings !
>>    
>>
>Could you provide some examples of variable declaration ? For what I've
>tried, it is not possible to prefix the name of the declared variable by ::.
>
>int ::x;        // failed to compile => can not force x to be in global
>namespace
>
>The only place I could see this work is when you are referering to variable
>x in some expression.
>

Declaration of class variables or variables of a namespace are using 
this syntax.

typedef int myint;

namespace nnnn {
   extern int x;
}

myint ::nnnn::x = 0;

Note that the problem only appears in case of userdefined type. Since 
than the syntax
specifies, that a userdefined type can be specified using "::". For this 
reason we can not
stop reading after "myint" and have to continue with "::nnnn". The 
parser does not know
where to stop if a "::" follows.

A second example is the use of class variables:

class nnnn {
    static int x;
};

myint ::nnnn::x = 0;

>
>  
>
>>>Concerning code clean-up, you might want to reuse the SourceBuilder class
>>>      
>>>
>we
>  
>
>>>use in the rfta library (or implement a similar class, more dedicated to
>>>      
>>>
>ast
>  
>
>>>node range). This would makes the tests easier to write, read and
>>>      
>>>
>maintain.
>  
>
>>I was thinking about that, but than decide a different solution.
>>For class body parsing I will check this test solution again.
>>I more and more understand your test routines ;-)...
>>    
>>
>
>I've looked at some of the tests, and there is some 'magical' constants
>appearing from nowhere for ast node range test. This makes it hard to
>understand what is the range of a given node. How did you figure out their
>values anyway ?
>
Counting by hand is the simple answer.
E.g. "const short int" has three specifiers.
They start at 0, 6, and 12. Their lengths are 5, 5, and 3.
I will clean this up a little bit !

>As for the test routines, they call it test driven design, or test first
>design. I just made the environment to make it possible for us ;-). It was
>actually the reason why I renounced to use Boost.Spirit (a generic
>programming parser framework). Compile time were huge (just including the
>headers in a cpp resulted in a compile time of around a minute !).
>  
>
I'm not sure yet, if the boost.spirit approach makes the parser better 
understandable, since
even reading the simple examples at the spirit pages don't make me say 
"wow that's it" ...
what do you think - did I miss some point which makes the "Spirit" worth 
for us ?

>I was thinking of something along the same lines. I've added a CPPParser
>class, which should ultimately become the main interface to the rftaparser
>library (at the current time, it's just a squeleton).
>
Yep that CPPParser is a nice idea.

>I'll also try to get something out so that we can run the new parser over a
>large number of sources and study the output (much like astdumper).
>
Yep, I also allready played arround with a modified version of ASTDump, 
but did not checked it in...

-- André