This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 Mon, Sep 10, 2012 at 10:41 AM, Aaron Gray <aaronngray.lists@gmail.com> wrote:

> 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.

Yes, for that, you need reduce the scope of your patch.

Use Occam's razor.  Do not move a declaration out of cp/parser.c unless
you have a compelling reason for it.  "Classization" is not sufficient argument.
A good interface is likely to be reduced to the essential.

I would suggest that you do not create any file out of cp/parser.c for the
moment.  Just focus on identifying the interface of the parser within
cp/parser.c.

Do no move data types out of cp/parser.c unless there is a good reason for it.
If an existing function does not "poke" into what should morally be
(private)  data members of the cp_parser struct, don't make it a
member function yet.  If a function does, then look at whether it can
be expressed in terms of more reduced set of  observer/mutator functions;
if that is the case, then do that.  Adding the observer/mutator function does
not change semantics.  Isolating the interface means isolating the computational
basis.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]