RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.github.io/LWG/issue2846 below:

Issue 2846: Undefined phrase "effectively cast"

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

2846. Undefined phrase "effectively cast"

Section: 29.4.10 [cmplx.over], 29.7.1 [cmath.syn] Status: New Submitter: Jens Maurer Opened: 2016-12-15 Last modified: 2019-03-18

Priority: 3

View all other issues in [cmplx.over].

View all issues with New status.

Discussion:

In [cmplx.over] and [cmath.syn], when talking about "sufficient additional overloads", we use the phrase "effectively cast", but that is not a defined term.

A hostile interpretation could read "reinterpret_cast" here. Likely we mean "apply floating-point promotions, floating-integral conversions, and floating-point conversions", but that should be spelled out somewhere, e.g. in the library definitions section. (Source: Editorial issue #1248)

[2017-01-27 Telecon]

Priority 3

[2019-03-16; Daniel comments and provides wording]

I decided to use the form "implicitly converted" and to refer to 7.3 [conv] for 29.7.1 [cmath.syn] and 29.4.10 [cmplx.over], because those conversions can all be done implicitly. This also holds for the pow specification 29.4.10 [cmplx.over] p3, because the described conversions of complex<T> to complex<U> involve only the need of non-explicit constructors.

Proposed resolution:

This wording is relative to N4810.

Change 29.4.10 [cmplx.over], as indicated:
-2- The additional overloads shall be sufficient to ensure:
1. (2.1) — If the argument has type long double, then it is effectively cast implicitly converted (7.3 [conv]) to complex<long double>.
2. (2.2) — Otherwise, if the argument has type double or an integer type, then it is effectively cast implicitly converted to complex<double>.
3. (2.3) — Otherwise, if the argument has type float, then it is effectively cast implicitly converted to complex<float>.
-3 Function template pow shall have additional overloads sufficient to ensure, for a call with at least one argument of type complex<T>:
1. (3.1) — If either argument has type complex<long double> or type long double, then both arguments are effectively cast implicitly converted (7.3 [conv]) to complex<long double>.
2. (3.2) — Otherwise, if either argument has type complex<double>, double, or an integer type, then both arguments are effectively cast implicitly converted to complex<double>.
3. (3.3) — Otherwise, if either argument has type complex<float> or float, then both arguments are effectively cast implicitly converted to complex<float>.
Change 29.7.1 [cmath.syn], as indicated:
-2- For each set of overloaded functions within <cmath>, with the exception of abs, there shall be additional overloads sufficient to ensure:
1. If any argument of arithmetic type corresponding to a double parameter has type long double, then all arguments of arithmetic type (6.9.2 [basic.fundamental]) corresponding to double parameters are effectively cast implicitly converted (7.3 [conv]) to long double.
2. Otherwise, if any argument of arithmetic type corresponding to a double parameter has type double or an integer type, then all arguments of arithmetic type corresponding to double parameters are effectively cast implicitly converted to double.
3. Otherwise, all arguments of arithmetic type corresponding to double parameters have type float.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4