This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 17.3.5 [numeric.limits] Status: CD1 Submitter: Martin Sebor Opened: 2006-02-19 Last modified: 2017-06-15
Priority: Not Prioritized
View other active issues in [numeric.limits].
View all other issues in [numeric.limits].
View all issues with CD1 status.
Discussion:
[limits], p2 requires implementations to provide specializations of the
numeric_limits template for each scalar type. While this
could be interepreted to include cv-qualified forms of such types such
an interepretation is not reflected in the synopsis of the
<limits> header.
The absence of specializations of the template on cv-qualified forms
of fundamental types makes numeric_limits difficult to
use in generic code where the constness (or volatility) of a type is
not always immediately apparent. In such contexts, the primary
template ends up being instantiated instead of the provided
specialization, typically yielding unexpected behavior.
Require that specializations of numeric_limits on
cv-qualified fundamental types have the same semantics as those on the
unqualifed forms of the same types.
Proposed resolution:
Add to the synopsis of the <limits> header,
immediately below the declaration of the primary template, the
following:
template <class T> class numeric_limits<const T>; template <class T> class numeric_limits<volatile T>; template <class T> class numeric_limits<const volatile T>;
Add a new paragraph to the end of 17.3.5 [numeric.limits], with the following text:
-new-para- The value of each member of a numeric_limits
specialization on a cv-qualified T is equal to the value of the same
member of numeric_limits<T>.
[ Portland: Martin will clarify that user-defined types get cv-specializations automatically. ]