This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching to C++ by default in 4.8

On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <> wrote:
> On 4/5/12, Richard Guenther <> wrote:
>> On Apr 4, 2012 Lawrence Crowl <> wrote:
>> > On 4/4/12, Richard Guenther <> 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

>> > > 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.


>> > > > 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]