This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 1281. CopyConstruction and Assignment between ratios having the same normalized form

Section: 20.16.3 [ratio.ratio] Status: Resolved Submitter: Vicente Juan Botet Escribá Opened: 2009-12-07 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [ratio.ratio].

View all issues with Resolved status.

Discussion:

CopyConstruction and Assignment between `ratio`s having the same normalized form. Current N3000 do not allows to copy-construct or assign `ratio` instances of `ratio` classes having the same normalized form.

Two `ratio` classes `ratio<N1,D1>` and `ratio<N2,D2>` have the same normalized form if

>     ratio<N1, D1>::num == ratio<N2, D2>::num &&
>     ratio<N1, D1>::den == ratio<N2, D2>::den

This simple example

>     ratio<1,3> r1;
>     ratio<3,9> r2;
>     r1 = r2; // (1)

fails to compile in (1). Other example

>     ratio<1,3> r1;
>     ratio_subtract<ratio<2,3>, ratio<1,3>>::type r2;
>     r1 = r2;

The nested type of `ratio_subtract<ratio<2,3>, ratio<1,3>>` could be `ratio<3,9>` so the compilation could fail. It could also be `ratio<1,3>` and the compilation succeeds.

In 20.16.4 [ratio.arithmetic] 3 and similar clauses

> 3 The nested typedef `type` shall be a synonym for `ratio<T1, T2>` where `T1` has the value `R1::num * R2::den - R2::num * R1::den` and `T2` has the value `R1::den * R2::den`.

the meaning of synonym let think that the result shall be a normalized `ratio` equivalent to `ratio<T1, T2>`, but there is not an explicit definition of what synonym means in this context.

Additionally we should add a typedef for accessing the normalized `ratio`, and change 20.16.4 [ratio.arithmetic] to return only this normalized result.

[ 2010 Pittsburgh: ]

> There is no consensus to add the converting copy constructor or converting copy assignment operator. However there was consensus to add the typedef.

> Proposed wording modified. Original proposed wording preserved here. Moved to Review.

> > Make `ratio` default constructible, copy-constructible and assignable from any `ratio` which has the same reduced form.

> > Add to 20.16.3 [ratio.ratio] synopsis

> > >     template <intmax_t N, intmax_t D = 1>
> > >     class ratio {
> > >     public:
> > >       static constexpr intmax_t num;
> > >       static constexpr intmax_t den;

> > >       typedef ratio<num, den> type;

> > >       ratio() = default;
> > >       template <intmax_t N2, intmax_t D2>
> > >         ratio(const ratio<N2, D2>&);
> > >       template <intmax_t N2, intmax_t D2>
> > >         ratio& operator=(const ratio<N2, D2>&);
> > >     };

> > Add to 20.16.3 [ratio.ratio]:

> > > Two ratio classes `ratio<N1,D1>` and `ratio<N2,D2>` have the same reduced form if `ratio<N1,D1>::type` is the same type as `ratio<N2,D2>::type`

> > Add a new section: [ratio.cons]

> > > Construction and assignment [ratio.cons]

> > >     template <intmax_t N2, intmax_t D2>
> > >       ratio(const ratio<N2, D2>& r);

> > > > Effects: Constructs a `ratio` object.

> > > > Remarks: This constructor shall not participate in overload resolution unless `r` has the same reduced form as `*this`.

> > >     template <intmax_t N2, intmax_t D2>
> > >       ratio& operator=(const ratio<N2, D2>& r);

> > > > Effects: None.

> > > > Returns: `*this`.

> > > > Remarks: This operator shall not participate in overload resolution unless `r` has the same reduced form as `*this`.

> > Change 20.16.4 [ratio.arithmetic]

> > > Implementations may use other algorithms to compute these values. If overflow occurs, a diagnostic shall be issued.

> > >     template <class R1, class R2> struct ratio_add {
> > >       typedef see below type;
> > >     };

> > > > The nested typedef `type` shall be a synonym for `ratio<T1, T2>::type` where `T1` has the value `R1::num * R2::den + R2::num * R1::den` and `T2` has the value `R1::den * R2::den`.

> > >     template <class R1, class R2> struct ratio_subtract {
> > >       typedef see below type;
> > >     };

> > > > The nested typedef `type` shall be a synonym for `ratio<T1, T2>::type` where `T1` has the value `R1::num * R2::den - R2::num * R1::den` and `T2` has the value `R1::den * R2::den`.

> > >     template <class R1, class R2> struct ratio_multiply {
> > >       typedef see below type;
> > >     };

> > > > The nested typedef `type` shall be a synonym for `ratio<T1, T2>::type` where `T1` has the value `R1::num * R2::num` and `T2` has the value `R1::den * R2::den`.

> > >     template <class R1, class R2> struct ratio_divide {
> > >       typedef see below type;
> > >     };

> > > > The nested typedef `type` shall be a synonym for `ratio<T1, T2>::type` where `T1` has the value `R1::num * R2::den` and `T2` has the value `R1::den * R2::num`.

[ 2010-03-27 Howard adds: ]

> Daniel brought to my attention the recent addition of the typedef `type` to the FCD N3092:

> >     typedef ratio type;

> This issue was discussed in Pittsburgh, and the decision there was to accept the typedef as proposed and move to Review. Unfortunately the issue was accidently applied to the FCD, and incorrectly. The FCD version of the typedef refers to `ratio<N, D>`, but the typedef is intended to refer to `ratio<num, den>` which in general is not the same type.

> I've updated the wording to diff against N3092.

[Batavia: NAD Editorial Resolved - see rationale below]

Rationale:

Already fixed in working draft

Proposed resolution:

Add to 20.16.3 [ratio.ratio] synopsis

>     template <intmax_t N, intmax_t D = 1>
>     class ratio {
>     public:
>       static constexpr intmax_t num;
>       static constexpr intmax_t den;

>       typedef ratio<num, den> type;
>     };