This is the mail archive of the gcc@gcc.gnu.org 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 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Apr 4, 2012 Lawrence Crowl <crowl@google.com> wrote:
> > On 4/4/12, Richard Guenther <richard.guenther@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.

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

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