Re: [lmi] Specializing std::numeric_limits?

[Vadim Zeitlin]

On Sat, 6 Mar 2021 23:24:09 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> https://git.savannah.nongnu.org/cgit/lmi.git/commit/?h=odd/eraseme_limits
GC> |
GC> | Although it's assuredly possible to specialize std::numeric_limits for
GC> | a UDT, it seems that almost nobody does.
GC> |
GC> | Perhaps this exercise shows that it's not generally advisable.
GC> 
GC> Vadim--Is std::numeric_limits as rarely specialized in practice as I
GC> infer from the meagerness of stackexchange discussions on this topic?

 I don't really know, but IMHO it doesn't make much sense to specialize it
for user-defined types, even if it is indeed allowed as some people seem to
think. I've always thought of this class as providing information about the
properties of arithmetic types of the concrete implementation and from this
point of view specializing it would only be useful if you could also define
new arithmetic types, but you can't do this.

GC> At any rate, lmi's class template minmax was originally intended to provide
GC> a "safe" cover for std::minmax_element(), hiding the pointers (which until
GC> today could have been null, so it wasn't safe) behind functions.

 Sorry, I couldn't understand this part. Which pointers do you mean here?

GC> Then it
GC> was enhanced, using std::numeric_limits to set a priori extrema...which
GC> were not "meaningful" according to the Standard in all actual use cases
GC> (fixed now). So we could have instantiated minmax<some_random_class>
GC> whose minimum() and maximum() would both have either returned zero,
GC> or segfaulted.

 If this class is only supposed to be used with arithmetic types (or maybe
even only floating point ones? AFAICS it's only used with double outside of
the tests), shouldn't we (statically) assert this fact directly?

GC> I think I've fixed the problems now, without specializing numeric_limits,
GC> except that the "maximum" double is DBL_MAX, and I know a double value
GC> that exceeds DBL_MAX (and one less than the "minimum", -DBL_MAX).

 Again, I don't know what is the intention here, i.e. whether we actually
want to use the infinities here. Mathematically it would make sense, of
course, but I'd have to spend much more time studying the code to
understand if it would be better or worse for the existing users of this
class.

 BTW, on a completely different note, looking at this code:

        auto const& extrema = std::minmax_element(v.begin(), v.end());
        minimum_ = *extrema.first ;
        maximum_ = *extrema.second;

I think it could be one of the few cases where std::tie() could be actually
useful, as it would allow writing this as

        std::tie(minimum_, maximum_) = std::minmax_element(v.begin(), v.end());

which is IMHO slightly more readable.

 Sorry for the lack of real answers to your questions,
VZ

pgpoOM9qnzeot.pgp
Description: PGP signature