Re: Switching to C++ by default in 4.8

[Xinliang David Li <davidxl@google.com>]

On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl <crowl@google.com> wrote:
>> On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote:
>>> 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).
>>
>> You do want to step into those inline functions, except when you do.
>> In the short term, we can make the debugger behave as though they did
>> not exist.  In the longer term, we really want debugging tools that
>> help C++ programmers.  One way to get there is to use C++ ourselves.
>
> Fix the debugger first please.
>
>>> > 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.
>>
>> If you just look at any decently sized code base, it'll look pretty
>> much unreadable.  The question is how quickly can someone who learns
>> the base vocabulary can produce reasonable modifications.
>>
>> There are many places where C++ can help substantially.  For example:
>>
>> () The C++ postfix member function call syntax means that following
>> a chain of attributes is a linear read of the expression.  With C
>> function call syntax, you need to read the expression inside out.
>
> It's a matter of what you are used to (consider LISP).
>
>> () C++ has both overloaded functions and member functions, so you can
>> use the same verb to talk about several different kinds of objects.
>> With C function names, we have to invent a new function name for
>> each type.  Such names are longer and burden both the author and
>> the reader of the code.
>
> Agreed.  Function overloading is one of the nice things that does not
> automatically make the code-base look "partial C++".  Likewise
> operator overloading can make things like
>
>            bit_offset = double_int_add (bit_offset,
>                                         tree_to_double_int
>                                           (DECL_FIELD_BIT_OFFSET (field)));
>
> be just
>
>           bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field);
>
> it still looks like C but with some C++ "magic".
>

Function overloading is both bless and curse. It makes code look
better, but may reduce debuggability.


>> () Standard C++ idioms enable mashing program components with ease.
>> The C++ standard library is based on mixing and matching algorithms
>> and data structures, via the common idiom of iterators.
>
> Sort-of agreed.  Though iterator-style (and more so functor style) was never
> one of my favorite.
>
>> () The overloadable operator new means that memory can be
>> _implicitly_ allocated in the right place.
>
> Implicit allocation is bad.  In a compiler you want to _see_ where you
> spend memory.

overload operator new per class allows memory management easier --
many different allocation policies (e.g pool based) can be easily
implemented.


>
>> () Constructors and destructors reduce the number of places in the
>> code where you need to do explicit memory management. Without garbage
>> collection, leaks are less frequent.  With garbage collection, you
>> have much less active garbage, and can run longer between collection
>> runs.  Indeed, a conservative collector would be sufficient.
>
> Time will tell.
>
>> () Constructors and destructors also neatly handle actions that
>> must occur in pairs.  The classic example is mutex lock and unlock.
>> Within GCC, timevar operations need to happen in pairs.
>
> Agreed.
>
>> () Class hierarchies (even without virtual functions) can directly
>> represent type relationships, which means that a debugger dump of
>> a C++ type has little unnecessary information, as opposed to the
>> present union of structs approach with GCC trees.
>
> In GCC trees only the "base" is a union, and it is so as implementation
> detail.  That gdb does not grok a 'tree' well is because gdb is stupid.
> All the information is there.
>
>> () Class hierarchies also mean that programmers can distinguish
>> in the pointer types that a function needs a decl parameter,
>> without having to say 'all trees' versus 'a very specific tree'.
>> The static type checking avoids run-time bugs.
>
> True.  In a very limited set of cases.  C++ is not powerful enough
> to express pointer-to-everything-that-would-be-considered-a-gimple-val.
> Maybe C++ is not the right choice after all?  (I suppose C++ concepts
> would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ...
> (though is_gimple_val is not be a static property).
>
>> I have written compilers in both C and C++.  I much prefer the
>> latter.
>
> Did you ever try to convert an existing large C codebase to C++?
> I would not expect a very good result and rather start from scratch.
> So I don't see that we ever arrive (or want to arrive) at a pure C++-style
> GCC.  Instead I expect we end up (and desire to end up) with GCC
> compiled with a C++ compiler that uses C++ features to make the
> existing style more readable and maintainable.

I like your proposal (from my reading) about keeping core APIs in C,
while the rest can be migrated (gradually).

thanks,

David
>
> Richard.
>
>> --
>> Lawrence Crowl