On 4/9/12, Richard Guenther <richard.guent...@gmail.com> wrote:
> On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <cr...@google.com> wrote:
>> On 4/5/12, Richard Guenther <richard.guent...@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
