This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h
On 10 September 2012 15:53, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> [ I am adding back GCC mailing list in the CC: as this would be useful
> for other contributors. ]
>
> On Mon, Sep 10, 2012 at 9:42 AM, Aaron Gray <aaronngray.lists@gmail.com> wrote:
>> On 10 September 2012 15:25, Gabriel Dos Reis <gdr@integrable-solutions.net>
>> wrote:
>>>
>>> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray <aaronngray.lists@gmail.com>
>>> wrote:
>>> > On 10 September 2012 14:35, Gabriel Dos Reis
>>> > <gdr@integrable-solutions.net>
>>> > wrote:
>>> >>
>>> >> On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray
>>> >> <aaronngray.lists@gmail.com>
>>> >> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > I have put in three patches on the 29th of August, but have not heard
>>> >> > any real feedback on them :-
>>> >> [...]
>>> >> > [PATCH] C++'ization of cp/parser.c/h
>>> >> >
>>> >> > http://gcc.gnu.org/ml/gcc-patches/2012-08/msg02018.html
>>> >> >
>>> >> >
>>> >> > This last patch possibly needs freshening, but all were tested and
>>> >> > tested with the GCC testsuite.
>>> >>
>>> >> You did receive a real feedback on the last patch.
>>> >
>>> >
>>> > Gaby,
>>> >
>>> > In reply, I was trying to do the first phase of a set of incremental
>>> > changes
>>> > towards normalizing the C++ frontend.
>>> >
>>> > Having looked at the complexity of parsing C++ and the complexity and
>>> > pragmatics of the semantics and the complexity of the GCC C++
>>> > "middleend"
>>> > code and know it to a degree then to have something working keep it
>>> > working
>>> > seems the best bet to me.
>>> >
>>> > So the interfaces can be made distinct and normalized while keeping the
>>> > code
>>> > running and passing the testsuite. Once the interfaces are distinct more
>>> > radical changes can be made.
>>> >
>>> > Just my 2cents,
>>> >
>>> > Aaron
>>> >
>>>
>>> Aaron,
>>>
>>> I am not sure I understand what you are saying.
>>> The patch I commented on was *radical* change from the current state, and
>>> there
>>> is no answer to why you needed to make such a radical change,
>>
>>
>> As I understand things we are C++'izing the GCC C++ frontend ?
>>
>> And encapsulation and class'ization seems to be the first step in doing that
>> I would have thought ?
>
> It is not clear what the benefit is to move existing perfectly working
> internal non-member functions to being member functions a huge struct.
>
> Encapsulation does not necessarily mean that all functions have to
> be member functions or that all data type definitions have to reside
> in a .h file. In fact, I would argue that the patch you posted reduced
> encapsulation and abstraction, as opposed to increasing it. Datatypes
> and member functions that have no business of being exposed to the
> entire world are now made public.
Next stage is to make the struct's classes and make most member
function private. I was not worried at this stage about exposing the
header as it is not used by ant other .c files except cp/cp-lang.c
which is not actually dependant upon parser.h hence my very basic
first patch.
>> My changes are orthogonal to the original code.
>
> No, they are not -- hence the comments.
please see above.
>
>> All I have done is create
>> classes out of the cp_lexer_* and cp_parser_* functions and moved a few
>> statics into the classes where it was logical and where there were no weird
>> dependencies stopping that being done.
>
> You did not provide a rationale of why it was logical to move those functions
> as you did. The comments I made looked at the heart of the changes you made.
Sorry I should have explained the whole approach.
What I am looking to obtain is isolating the C++ parser with no real
semantic changes, just isolating the interfaces in order that the
parser be reusable as a library component and allow migration to other
solutions.
Aaron