On 10 September 2012 15:53, Gabriel Dos Reis <g...@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.li...@gmail.com> > wrote: >> On 10 September 2012 15:25, Gabriel Dos Reis <g...@integrable-solutions.net> >> wrote: >>> >>> On Mon, Sep 10, 2012 at 8:59 AM, Aaron Gray <aaronngray.li...@gmail.com> >>> wrote: >>> > On 10 September 2012 14:35, Gabriel Dos Reis >>> > <g...@integrable-solutions.net> >>> > wrote: >>> >> >>> >> On Mon, Sep 10, 2012 at 8:23 AM, Aaron Gray >>> >> <aaronngray.li...@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
