On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> >> Class hierarchy is one such feature that is useful. Assuming we have
> >> two hierarchies for gcc: one for values rooted at ValExp, and one for
> >> gimple stmts rooted at GimpInst.
> >>
> >> 1) For IR browsing,
> >> *) all the macro accessors can be eliminated -- a big plus for
> >> debugging;
> >
> > Not that clear, if all the macros are replaced by tons of inline functions,
> > the debugging experience can be actually significantly worse. Already some
> > the
> > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH
> > macro are extremely annoying from debugging POV.
>
> What is the root cause of the annoyance? Mixing macros and inline
> functions does not sound good, but using deeply nested macros do not
> seem to help the debugging situation either.
That when stepping through code in the debugger you keep enterring/exiting
these one liner inlines, most of them really should be at least by default
considered just as normal statements (e.g. glibc heavily uses artificial
attribute for those, still gdb doesn't hide those by default).
> > Not to mention it is very questionable if the above stuff is more readable
> > than what we currently have.
>
> The above is just quickly cooked up examples. A carefully designed C++
> based API can be self documenting and make the client code very
> readable. It is hard to believe that there is no room for improvement
> in GCC.
Do you have examples? E.g. I haven't touched gold, because, while it is a new
C++ codebase, looks completely unreadable to me, similarly libdw C++ stuff.
A carefully designed C based API can be self documenting and make the code
very readable as well, often more so.
Jakub
