Re: Switching to C++ by default in 4.8

[Lawrence Crowl <crowl at google dot com>]

On 4/9/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <crowl@google.com> wrote:
>> On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote:
>>> How do you expect tree errors to become static?  By using derived
>>> types everywhere?  Note that this would only be possible in a
>>> _very_ limited sub-set of places.
>>
>> Yes, a class hierarchy that directly represents the type hierarchy
>> already implicit in trees.  With that structure in place, functions
>> that require a certain kind of tree as a parameter can say so
>> directly in the parameter list.  Functions that return a certain
>> kind of tree can say so in the return type.  Calling a function
>> that is inappropriate to the type will result in a static error.
>>
>> Certainly there are cases where the type must be made more specific,
>> and getting the wrong type here would necessarily be a dynamic check.
>> However, the number of dynamic checks can be substantially reduced.
>> To provide a specific example, suppose I have a common_decl *p and
>> need to do extra work if it is a var_decl.
>>
>> do_general_work (p);
>> if (var_decl *q = p->to_var ())
>> {
>>  do_var_work_1 (q);
>>  do_var_work_2 (q);
>>  do_var_work_3 (q);
>>  do_var_work_4 (q);
>> }
>>
>> The only dynamic work is in the pointer conversion.  All other
>> function calls can be statically typed.
>
> Ok.  But the above represents a completely different programming
> style than what we use currently.  We do
>
>   if (is_var_decl (p))
>     {
>        do_var_work_1 (p);
> ...
>     }
>
> so what I was refering to was static errors we get when we are
> able to promote function argument / return types to more specific
> sub-classes.

Certainly fully exploiting a class hierarchy will require a
migration of the source base.  That can happen incrementally over
time.  In the meantime, there are other tasks that will show more
immediate progress.

>>> > > I expect the GCC core to maintain written in C, compiled
>>> > > by C++.
>>> >
>>> > Converting VECs to C++ vectors vector would provide significant
>>> > code clarity benefits.  The files in which that is done would
>>> > necessarily be C++ only.
>>>
>>> I already had VECs as the very first and best example why C++
>>> might be good.
>>
>> But my point was that if we're using a C++ vector, the files are
>> not written in C any more.
>
> Of course - the whole point was to switch to C++ and start using
> C++ features.  The point I wanted to raise is that the switch to
> C++ should happen with a change that is useful and that includes
> getting GC "right".  Converting vec.h is such a change.

A build conversion to C++ is a precondition to any source change
using C++, though the two could be bundled into one patch.  In any
event, I agree that the conversion needs to provide value. Vectors
and hash tables are a good early target.

-- 
Lawrence Crowl