Re: [Opencxx-users] opencxx refactoring

[Grzegorz J. <ja...@ac...>]

Stefan Seefeld wrote:
> Gilles J. Seguin wrote:
> 
>> Templates make a C++ parser at least 'x' times harder.
>> Can you explain how we can handle template specialization with current
>> parser.
>>
>> What I understand,
>> - specializing templates requires that the tokens for a template
>>   declaration be saved so that the template can be reprocessed when the
>>   actual template arguments are specified.
> 
> 
> I'm not sure whether that is necessary. It might be if you wanted to
> do some validation such as make sure that the types on which a template
> should be instantiated fulfill the requirements of the template.
> I don't think this is all that useful at the moment.

Unfortunately it all is necessary. Consider this:

class Q : public Foo<int>::type
{
};

You need to have full templates support in order to get the base class of Q.

However, if you restrict yourself just to parsing, then you need only 
one thing: you need to know if an identifier is a template (and this 
knowledge is necessary only when parsing expressions, to resolve between 
'<' and '>' being angle brackets or relational operators).

> Existing difficulties in resolving ambiguities during template parsing
> aside, I believe everything we need is already in place. The parser
> can parse both template declarations as well as template specializations.
> We only need to look up the first when we run into the second. All we
> need is an environment...
> 
>> - it requires the syntax phase to perform near-complete type, scope, and
>>   expression analysis, including function overloading.
> 
> 
> Right, it would, if we tried to validate the code.
> 
>> So my believed is that we need to rejuvenate the design.
>> But my question is how.
> 
> 
> Functionality-wise I believe the big issue is with ambiguities the current
> parser can't resolve due to the two-phase parsing. We should try to merge
> these two phases into one, as we discussed in another thread.

Agreed.

> Another issue is that of the code being quite monolithic. Now that I'v
> had some first cut at a refactoring I'm more convinced than ever that
> it is possible to clear up the code substantially, and thus make it simpler
> to use and enhance (the old topic of a new AST API on top of the PTree 
> stuff comes to mind !).
> 
> As far as synopsis is concerned, I'm looking into exposing these APIs
> to python and then being able to script on top of that. 

That would also facilitate unit testing, right?

BR
Grzegorz


> That would remove
> the need for a complete, portable C++ application frontend, i.e. I believe
> it's far easier to write an 'occ' application in python, where running
> subprocesses and loading plugins is far more simple and portable then
> doing the same in C/C++. Just imagine, we could completely drop all this
> libtool / lddl business...!
> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users