0

With the new features of C++17, is it possible to create a better std::min and std::max?

What I mean by better:

  • std::min/max has the problem of dangling references.
  • std::min/max doesn't work with different types (i.e., min(short, int) needs to explicitly specify the type min<int>(...))

I'd like to have a better implementation, which:

  • avoids the dangling reference problem (for example, min(a, 4); works correctly)
  • works with different types (for example, min((short)4, (int)8); compiles)
  • avoids unnecessary object copies (for example, if I have a class which represents a big integer, it only copies it when it is unavoidable)

Is it possible to do this, or is std::min/max the current best solution which one can have?

geza
  • 28,403
  • 6
  • 61
  • 135
  • 1
    Anything is possible.... – user1231232141214124 Nov 20 '17 at 17:43
  • What answer do you expect? "Yes" is a bit short, "yes here it is" is too broad. For the right definition of "better" you can surely find a better version. – nwp Nov 20 '17 at 17:43
  • 1
    Define better. :-) For example, when used with different types, what type should it return? – Bo Persson Nov 20 '17 at 17:46
  • @BoPersson `std::common_type_t` of course. – nwp Nov 20 '17 at 17:48
  • 2
    -7 for this seems a little aggressive. Does the question really show insufficient research effort, clarity, or usefulness? "Too broad", maybe, but not... -7... – Barry Nov 20 '17 at 17:57
  • @BoPersson: yes, it needs some design work, but I don't think that there is too much possibility for that... – geza Nov 20 '17 at 18:06
  • @Barry: I did research this. And haven't found anything, which fulfills my needs. Hence the question. – geza Nov 20 '17 at 18:08
  • @nwp: I expect some implementation which fulfills what I described. If it is too broad, can you please tell, which part is too broad? We're talking about a thing, which should be dead simple, `min`. – geza Nov 20 '17 at 18:10
  • 1
    That's even worse. "Here are the requirements. Write the code for me". SO typically doesn't like those "questions". Normally you just attempt to implement it, get stuck and ask about a specific issue. Or you succeed and post it on codereview.so. This is just lazy. – nwp Nov 20 '17 at 18:21
  • 5
    @nwp: it is not "for me". It is for everyone. That's a huge difference. A better min/max would be good for everyone, not just me. – geza Nov 20 '17 at 18:25

1 Answers1

5

Here's an old and failed proposal for a better min/max using just C++11 tech:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2199.html

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • 1
    Any color on the failure? Viewed as harmful or simply insufficiently beneficial? – Barry Nov 20 '17 at 18:01
  • 1
    The comment at the time was that the implementation was embarrassingly complicated. For a while this paper was actually the butt of jokes. Since then, ironically, parts of the implementation have actually been standardized. E.g. `promote` is now `std::common_type`. – Howard Hinnant Nov 20 '17 at 18:13
  • Thanks for the answer! Why is it a problem, if it is complicated? If it does the job well... – geza Nov 20 '17 at 18:18
  • 1
    I wish you had been in that room a decade ago to ask that question! :-) – Howard Hinnant Nov 20 '17 at 18:22
  • :) To be honest, I don't find this complicated at all. Yes, it seems that it is much code, but it is not. C++ is just very verbose for these kind of tasks. – geza Nov 20 '17 at 18:28
  • I need to restructure this a little bit, so this can be used for used types as well (the `promote` template need to be specialized). – geza Nov 20 '17 at 19:12
  • 1
    I recommend subbing in `std::common_type` for `promote`, which also allows specialization on user-defined types. – Howard Hinnant Nov 20 '17 at 19:13