-1- The numeric_limits class template provides a C++ program with information about various properties of the implementation's representation of the arithmetic types.
[Drafting Note: It is unclear whether the requirement in the following paragraph 2 is intended to apply to program-defined specializations as well. Consider as an example a user-defined arithmetic-like type that provides arbitrary precision arithmetic which may require dynamic memory for certain object constructions. Is it invalid to specialize
If we want to make this restriction relaxed for program-defined specializations, further wording would be needed to give that permission]numeric_limitsfor such a type or may the program-defined specialization deviate from this requirement for at least some of its members?
-2- For all members declared static constexpr in the numeric_limits template, specializations shall define these values in such a way that they are usable as constant expressions.
numeric_limits primary template, all data members are value-initialized and all member functions return a value-initialized object. [Note 1: This means all members have zero or false values unless numeric_limits is specialized for a type. — end note] -4- An implementation shall provide s Specializations shall be provided for each arithmetic type, both floating-point and integer, including bool. The member is_specialized shall be istrue for all such specializations of numeric_limits. -5- The value of each member of a specialization of numeric_limits on a cv-qualified type cv T shall be equal to the value of the corresponding member of the specialization on the unqualified type T.
[Drafting Note: If we had introduced
Interestingly currently there doesn't exist a specification that defines under which situations the static membernumeric_limitstoday we would likely have only allowed to provide specializations for cv-unqualified program-defined types, but that ship has sailed long ago.is_specializedshould be definedtrueorfalse(This touches LWG 205(i)). The wording below does not attempt to improve that situation, but at least clarifies that its value may be different from that of the primary template. Note that this proposed wording does — opposed to the approach of LWG 3922(i) — not restrict that specializations can only be provided by program-defined types "emulating an arithmetic type", because that would break existing specializations and is also problematic in the light of the non-existing definition of that term. The below wording strategy gives permission to specializenumeric_limitsonly for non-array object types. An alternative approach could make it a precondition instead to instantiate the template for non-array object types, for example.]
-?- A program may specialize the numeric_limits template for a program-defined non-array object type. Such a specialization is permitted to define a value for any static member that differs from what the primary template would have defined, as appropriate for that type.
[Drafting Note: The following restriction is carefully drafted to ensure that a library has the freedom to provide such specializations for "extended" types (That are not necessarily integer-class types). The restriction is intended to apply only to "official" (strict) C++ standard library types]
-6- An implementation shall not provide specializations for n Non-arithmetic standard types of the C++ standard library, such as complex<T> (29.4.3 [complex]) , unless specified otherwise (e.g. for integer-class types, 24.3.4.4 [iterator.concept.winc]) , shall not have specializations.
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