Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a reason why numeric_limits do not work on reference types?

If you mistakenly do something like:

#include<limits>
int arr[3];
auto x  = std::numeric_limits<decltype(arr[0])>::max();

You will get unhelpful error message from the file in the STL implementation.

Problem is that template argument is a reference, so the fix is to remove it:

auto x  = std::numeric_limits<std::remove_reference_t<decltype(arr[0])>>::max();

Now my question is why numeric_limits do not know to do this by themselves? I would understand that you do not want to remove pointerness(since max of char pointer and max of char are very very different things), but I would assume that whenever you have a reference as an argument to numeric_limits you would be happy with result that is obtained by removing it.

like image 393
NoSenseEtAl Avatar asked Aug 17 '18 13:08

NoSenseEtAl


People also ask

What is numeric_ limits in c++?

std::numeric_limits ::digits in C++ with Example The std::numeric_limits ::digits function is used to find the number of radix digits that the data type can represent without loss of precision.

Which of the following data types is accepted by the Numeric_limits function?

Data types that supports std::numeric_limits() in C++ std::numeric_limits<int>::max() gives the maximum possible value we can store in type int. std::numeric_limits<unsigned int>::max()) gives the maximum possible value we can store in type unsigned int.


1 Answers

From a technical point of view, there is no reason why std::numeric_limits<T> couldn't work with references. All what would be needed it to add a partial specialisations like this:

namespace std {
    template <typename T> struct numeric_limits<T&>: numeric_limits<T> {};
    template <typename T> struct numeric_limits<T&&>: numeric_limits<T> {};
    template <typename T> struct numeric_limits<T const>: numeric_limits<T> {};
    template <typename T> struct numeric_limits<T volatile>: numeric_limits<T> {};
    template <typename T> struct numeric_limits<T const volatile>: numeric_limits<T> {};
}

A user can't add these specialisations, of course. However, that's not a huge constraint as a custom variant of numeric_limits can be created in a suitable namespace.

As it is technically doable the question now becomes why the standard doesn't provide these declarations. I don't think there will be a conclusive answer (unless this idea was discussed and discarded with a suitable and still accessible record). Here are some of the potential answers:

  1. The feature wasn't proposed. When std::numeric_limits was introduced it specifically targeted replacing the macros in <limits.h> with a more a C++ approach. Something like decltype(expr) and forwarding references didn't exist, i.e., template arguments wouldn't be "accidentally" deduced as reference types. Thus, removing qualifiers wasn't a concern at the time.
  2. I'm not sure if at the point in history when numeric_limits were added partial template specialisation already existed. Even if it existed, anything resembling template meta programming didn't exist. As a result, it may not have been possible or assumed to be possible to meddle with the template argument type in the necessary way.
  3. Even if it were considered, I doubt the committee would have gone with adding the partial specialisations: numeric_limits<T> inspects the traits of type T but reference types don't have a max() or digits. Also, if reference types are supported because "clearly" the desired property must be the one of the underlying type where to stop: should std::numeric_limits<int*>::max() provide the same value as std::numeric_limits<int>::max(), too? After all, it also doesn't make any sense on pointers.
  4. Considering that the original proposal almost certainly didn't cover the case of qualified types (see above), another reason why the feature isn't available is that it simply wasn't proposed: without a proposal the standard won't get changed. Whether the standard would get changed if the feature were proposed is a separate question. There is a proposal in this general space (P0437r0) but browsing over it I don't think this proposal covers qualified types, either.
like image 115
Dietmar Kühl Avatar answered Oct 23 '22 06:10

Dietmar Kühl