This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 17.3.5[numeric.limits]Status:CD1Submitter: Martin SeborOpened: 2006-02-19Last modified: 2017-06-15
Priority:Not Prioritized
View otheractive issues in [numeric.limits].
View all otherissues in [numeric.limits].
View all issues withCD1 status.
Discussion:
[limits], p2 requires implementations to provide specializations of thenumeric_limits
template for each scalar type. While thiscould be interepreted to include cv-qualified forms of such types suchan interepretation is not reflected in the synopsis of the<limits>
header.
The absence of specializations of the template on cv-qualified formsof fundamental types makesnumeric_limits
difficult touse in generic code where the constness (or volatility) of a type isnot always immediately apparent. In such contexts, the primarytemplate ends up being instantiated instead of the providedspecialization, typically yielding unexpected behavior.
Require that specializations ofnumeric_limits
oncv-qualified fundamental types have the same semantics as those on theunqualifed forms of the same types.
Proposed resolution:
Add to the synopsis of the<limits>
header,immediately below the declaration of the primary template, thefollowing:
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 followingtext:
-new-para- The value of each member of anumeric_limits
specialization on a cv-qualified T is equal to the value of the samemember ofnumeric_limits<T>
.
[Portland: Martin will clarify that user-defined types get cv-specializationsautomatically.]