On Mon, Aug 13, 2012 at 5:32 AM, 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.
>
> 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.
-- Gaby
