[PATCH] Fix private constructor for ScaledNumber.

Diego Novillo dnovillo at google.com
Thu Apr 30 05:55:38 PDT 2015


On Wed, Apr 29, 2015 at 4:52 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > +#define SCALED_NUMBER_SHIFT(op, base)
>         \
> > +  template <class DigitsT>
>        \
> > +  ScaledNumber<DigitsT> operator op(const ScaledNumber<DigitsT> &L,
>         \
> > +                                    int16_t Shift) {
>        \
> > +    return ScaledNumber<DigitsT>(L) base Shift;
>         \
> > +  }
> > +SCALED_NUMBER_SHIFT(<<, <<= )
> > +SCALED_NUMBER_SHIFT(>>, >>= )
> > +#undef SCALED_NUMBER_SHIFT
>
> With only two in this group, do you think the macro is still adding
> value?  If not, feel free to rewrite without the macro.  Up to you.
>

Good point. Done.


>
> > -  // 64-bit division is hard to test, since divide64 doesn't
> canonicalized its
> > +  // 64-bit division is hard to test, since divide64 doesn't
> canonicalize its
>
> Maybe commit this separately?  It seems unrelated.
>
>
Done.



> >    // output.  However, this is the algorithm the implementation uses:
> >    //
> >    // - Shift divisor right.
> > @@ -532,4 +532,17 @@
> >    EXPECT_EQ(SP64(0, 0), getDifference64(1, -64, 1, -1));
> >  }
> >
> > +TEST(ScaledNumberHelpersTest, arithmeticOperators) {
>
> Can you duplicate all the EXPECTs here for `uint64_t` as well?
>
>
Done.


> > +  EXPECT_EQ(ScaledNumber<uint32_t>(1, 3) + ScaledNumber<uint32_t>(1, 1),
> > +            ScaledNumber<uint32_t>(10, 0));
>
> IIRC, the error messages for EXPECT look better if the expected value
> is the LHS of the macro.  It prints something like this when it fails:
>
>     Expected value: <LHS>
>     Actual value:   <RHS>
>
> So it would be better if you reversed the arguments for all of these.
>

Done.


>
> > +  EXPECT_EQ(ScaledNumber<uint32_t>(1, 3) - ScaledNumber<uint32_t>(1, 1),
> > +            ScaledNumber<uint32_t>(6, 0));
> > +  EXPECT_EQ(ScaledNumber<uint32_t>(1, 3) * ScaledNumber<uint32_t>(1, 1),
> > +            ScaledNumber<uint32_t>(2, 3));
> > +  EXPECT_EQ(ScaledNumber<uint32_t>(1, 3) / ScaledNumber<uint32_t>(1, 1),
> > +            ScaledNumber<uint32_t>(1, 2));
> > +  EXPECT_EQ(ScaledNumber<uint32_t>(1, 3) >> 1,
> ScaledNumber<uint32_t>(1, 2));
> > +  EXPECT_EQ(ScaledNumber<uint32_t>(1, 3) << 1,
> ScaledNumber<uint32_t>(2, 3));
>
> For clarity, I'd spell this last expected value as
> `ScaledNumber<uint32_t>(1, 4)`.  I think that makes it easier to
> compare with the previous line.
>

Done.


> For clarity, these last two didn't previously compile for `uint64_t`,
> did they?  (If they did, then I'm confused...)
>

Right. This test case does not even compile without the patch.


Thanks. Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150430/cd3b4a6e/attachment.html>


More information about the llvm-commits mailing list