Title
numeric_limits primary template definition
Status
open
Section
[numeric.limits]
Submitter
Richard Smith

Created on 2016-06-09.00:00:00 last changed 11 months ago

Messages

Date: 2023-04-18.09:36:32

[ 2023-04 ]

See Walter's paper P1841 for the preferred direction.

Date: 2018-11-12.05:21:03

[ 2018-11 San Diego Thursday night issue processing ]

See Walter's paper P0437 for ideas and/or future directions.

Date: 2016-11-15.00:00:00

[ 2016-11-12, Issaquah ]

Sat PM: This looks like a good idea. Jonathan and Marshall will do post C++17 implementations and report back.

Date: 2016-06-09.00:00:00

I've received this report at the project editor mail alias, and it seems like it may be worthy of a LWG issue:

I recently had this problem:

  • I was storing data in a vector of __uint128_ts
  • I used a sorting library which used numeric_limits<T>::max() as a sentinel value
  • GCC's libstdc++ provides a numeric_limits specialisation for that type, but
  • Clang's libc++ does not.

This broke the sorting for me on different platforms, and it was quite difficult to determine why. If the default numeric_limits didn't default to 0s and false values (18.3.2.4 of N4582), and instead static_asserted, causing my code to not compile, I would have found the solution immediately.

I know that __uint128_t is non-standard, so neither GCC nor Clang is doing the wrong thing nor the right thing here. I could just submit a patch to libc++ providing the specialisations, but it doesn't fix the problem at its core.

I am wondering, what is the rationale behind the defaults being 0 and false? It seems like it is inviting a problem for any future numeric types, whether part of a library, compiler extension, and possibly even future updates to C++'s numeric types. I think it would be much better to prevent code that tries to use unspecified numeric_limits from compiling.

An alternative to this suggestion would be to still define the primary template, but not provide any of the members except is_specialized. Either way, this would make numeric_limits members SFINAEable.

Along the same lines, one might wonder why the members that only make sense for floating-point types are required to be defined to nonsense values for integer types.

History
Date User Action Args
2023-04-18 09:36:32adminsetmessages: + msg13531
2018-11-12 05:21:03adminsetmessages: + msg10212
2016-11-21 05:09:01adminsetmessages: + msg8662
2016-11-21 05:09:01adminsetstatus: new -> open
2016-06-09 00:00:00admincreate