On 8/13/12, Gabriel Dos Reis <g...@integrable-solutions.net> wrote:
> On Aug 13, 2012 Marc Glisse <marc.gli...@inria.fr> wrote:
> > On Mon, 13 Aug 2012, Jakub Jelinek wrote:
> > > On Sun, Aug 12, 2012 at 11:30:59PM +0200, Marc Glisse wrote:
> > > > > +inline double_int &
> > > > > +double_int::operator ++ ()
> > > > > +{
> > > > > + *this + double_int_one;
> > > >
> > > > *this += double_int_one;
> > > > would be less confusing.
> > >
> > > Do you mean that *this + double_int_one; alone also works,
> > > just is confusing? That would mean operator+ has side-effects,
> > > right?
> >
> > It "works" in that it compiles. It is confusing because the
> > addition is dead code and thus operator++ is a nop. Sorry for
> > my confusing euphemism, I should have called it a bug. operator+
> > has no side-effects AFAICS.
>
> yes, it is just as confusing and a bug as
>
> 2.3 + 1;
>
> is in plain C.
Yes, it is a bug. It's a bit disturbing that it wasn't caught
in bootstrap.
> > Note that there are many obvious places where this operator can be used:
> >
> > varasm.c: i = double_int_add (i, double_int_one);
> > tree-vrp.c: prod2h = double_int_add (prod2h, double_int_one);
> > tree-ssa-loop-niter.c: bound = double_int_add (bound, double_int_one);
> > tree-ssa-loop-niter.c: *nit = double_int_add (*nit, double_int_one);
> > tree-ssa-loop-ivopts.c: max_niter = double_int_add (max_niter,
> > double_int_one);
> > gimple-fold.c: index = double_int_add (index, double_int_one);
> >
> > etc.
> >
> > As a side note, I don't usually like making operator+ a
> > member function. It doesn't matter when there is no implicit
> > conversion, but if we ever add them, it will make addition
> > non-symmetric.
>
> As not everybody is familiar with C++ litotes, let me expand
> on this. I believe you are not opposing overloading operator+ on
> double_int. You are objecting to its implementation being defined
> as a member function. That is you would be perfectly fine with
> operator+ defined as a free function, e.g. not a member function.
In the absence of symmetric overloading, the code is slightly
cleaner with operators as member functions. It is easy to change
should we need symmetric overloads because, for the most part,
the change would have no effect on client code.
--
Lawrence Crowl
