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:
>> On Apr 4, 2012 Lawrence Crowl <cr...@google.com> wrote:
>> > On 4/4/12, Richard Guenther <richard.guent...@gmail.com> wrote:
>> > > Making tree or gimple a C++ class with inheritance and
>> > > whatever is indeed a huge waste of time and existing developer
>> > > ressources (that, if only because they have to adapt and
>> > > maintain two completely different code-bases over some time).
>> >
>> > Trees are presently a significant problem in that many static
>> > errors become dynamic errors, which entails more debugging.
>>
>> 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.
>> > > 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.
Richard.
>> > > > I also find debugging C++ in gdb somewhat more annoying
>> > > > than debugging plain C, and at the moment I always go back
>> > > > to a stage1 compiler.
>> > >
>> > > Indeed - I'd be worried if my debugging efficiency decreases
>> > > by more than 5%.
>> >
>> > If the number of debugging sessions was reduced by the same
>> > amount, the result would be a net wash.
>>
>> I have no expectation that the number of debug sessions will
>> be reduced.
>
> On the other hand, I do. There are many instances were I've debugged
> a problem to realize that it could have been a static type error.
>
> --
> Lawrence Crowl
