The MIN Challenge | Hacker News Reader

The MIN Challenge

rus.har.mn

44 pointseatnumber122 comments

Macros in C can sometimes be nasty, but "min" is a pathological case for a macro because it isn't what macros were meant for.

In reality "min" should just be a function, and you should write a separate function for each type you want to define it over. This is how this problem is solved in C, and almost all other languages. It just looks deceptive because C's native operators like "<" and ">" happen to be generic across some number types. This is just for convenience, it isn't how C is meant to be programmed. Pretty much every other language also makes you define different implementations of functions when you have a different type you want it to work on. Lots let you type the same function name, independent of the type - via generics, interfaces, or type-classes - but all call out to different implementations at the end of the day. Very few can derive those implementations.

As far as I am concerned, Macros in C are best used just to save on typing. They get a lot of hate because the syntax looks like functions - so people try to use them as functions. I don't recommend using them as functions, instead use them to save typing - because saving typing and avoiding repeating yourself can only reduce errors.

exactly my attitude towards them - modern compilers will generally optimise simple functions like "min" so that they're just as efficient as macro equivalents.

For example, for a project that I did, I needed specific access methods for each member of a struct, and for each method to be written with a separate function. With macros, it was as easy as defining a macro to generate said function (given the member name), and then calling said macro for each member to generate the code.

In my experience, some compilers will inline functions when it is an optimization (particularly if you declare them static inline).

"min" is a pathological case for a macro because it isn't what macros were meant for.

Tell that to Kernighan and Ritchie. The second macro in K&R (I googled a PDF of the second edition) is

  #define  max(A, B)  ((A) > (B) ? (A) : (B))

Yes, that's lowercase 'max', and they even mention "This macro will work for any data type; there is no need for different kinds of max for different data types, as there would be with functions"

Macros certainly were intended for this, as it was the only way to guarantee that the compiler inlined code (probably the only way it ever inlined function calls)

And for the curious: the first macro they give is

  #define  forever  for(;;)

That certainly is what macros were meant for :-), and doesn't even save on typing.

But yes, in modern C, nobody would use a macro for this.

The issue is for some programmers propensity to use ++ and -- whenever they can. So you end up with

    max(a++, b--)

Which expands to

    ((a++)>(b--)?(a++):(b--))

creating unexpected results. The solution is, don't use return values of `++` and `--` in calls, unless you know it's a function, and always will be. Upper-case macros may help, but then you need to make sure all macros are upper case.

> In reality "min" should just be a function, and you should write a separate function for each type you want to define it over. This is how this problem is solved in C, and almost all other languages.

This is not how it's solved in any languages with any degree of polymorphism. Of course, C is entirely devoid of polymorphism – except for its math operators like `<` and `+` – so having a version of `min` for every type you ever want to take a min of is how you're forced to do things. But no, `min` is not pathological – it's completely normal for math programming. If you look at math libraries written in monomorphic languages like C and Fortran – BLAS and LAPACK, or hell, just math.h – they are full of multiple nearly identical versions of functions that take different argument types and begin and/or end in different letters to indicate these types: `round`, `roundl`, `roundf`, etc. In LAPACK, it's completely conventional – "s" for single float, "d" for double float, "c" for single complex, "z" for double complex [1]. You'll note that the LAPACK naming scheme also encodes the type of matrix it operates on (there are 28 of them).

That's all fine, right? Well, it's fine if you're ok with writing every function four times. And that's only dealing with polymorphism in one argument. Hint: it's not at all uncommon for math functions to take multiple arguments. This is precisely why the first thing that a principled approach to mathematical programming does is allow polymorphism – ideally on multiple arguments. This is why people do math work in dynamic languages with lots of polymorphism, like Mathematica, Matlab, R and Python. Otherwise you can't get any work done without writing everything dozens of times – or struggling with C macro programming that makes this min puzzle look utterly tame. Sussman et al.'s SICM (SICP but for classical mechanics), not content with a dynamic language, immediately builds a multiple dispatch system on top of Scheme. R supports an awkward multiple dispatch system in one of its four object systems. This is why Guy Steele included multiple dispatch in Fortress. This is why Julia has multiple dispatch as its core paradigm. You need it for math. Badly.

[1] http://www.netlib.org/lapack/lug/node24.html

This is a lot more subtle than most programmers realize, thanks to floating point weirdness.

An essential property of MIN is that it is symmetric with respect to its arguments: MIN(a, b) and MIN(b, a) are the same thing. But the expression (a < b ? a : b) is not symmetric with NaNs. So what do we do?

We could assert that if only one value is an NaN, we return the other value. We might write it like this:

    if (a != a) return b;
    return a < b ? a : b;

This isn't symmetric if both arguments are different NaNs, but in practice getting different NaNs takes some work. (Note that C99 requires that fmin behave this way with respect to NaN.)

But we're still not quite symmetric, thanks to negative zero. Negative zero compares equal to positive zero, but it doesn't seem right that the sign bit of the result should depend on the argument order.

glibc doesn't bother to handle negative zero, but Java's Math.min does:

    public static double min(double a, double b) {
        if (a != a) return a;
        if ((a == 0.0d) && (b == 0.0d)
            && (Double.doubleToLongBits(b) == negativeZeroDoubleBits)) {
            return b;
        }
        return (a <= b) ? a : b;
    }

Delightful. Java has the best min.

Yes, C doesn't have generics. In practice most C code uses the fourth version, and you just have to remember not to put things with side effects as macro arguments.

#define MIN(a, b) ((a) < (b) ? (a) : (b))

C11 does introduce very limited type-variant macros.

Yep, but for min the C11 generics would work just as well and allow for a bit more flexibility than the older approaches.

Though you do have to name mangle manually and they aren't quite as powerful as you'd probably want.

http://www.robertgamble.net/2012/01/c11-generic-selections.h...

Can anyone explain the advantage of macros like this, rather than just using an `inline function`?

Is it because C doesn't have generics?

Yes, exactly that.

In older C, people tended to be unwilling to trust the compiler's ability to inline functions, so there was a lot of use of macros to avoid small repeated function calls.

Meanwhile, in C++14:

    auto min = [] (auto a, auto b) { return a < b ? a : b; };

Meanwhile, in Haskell:

    min x y = Data.Bool.bool x y (x > y)

Although considering what the article was talking about, doing stuff like this only makes you sound like an ass.

I have come to really dislike people who think it's a good idea to define macros such as min, max, major and minor in system headers.

* http://msdn.microsoft.com/en-us/library/windows/desktop/dd75...

* https://stackoverflow.com/questions/22240973/major-and-minor...

Unfortunately, the solution ultimately proposed doesn't work in this case:

  int _a = 50;
  int result = min(num, _a);

you end up expanding to "int _a = _a;" which creates a new int _a, and assigns it to itself.

Not entirely related to the post, but what's the sane use case for doing:

  return (expr, expr)

like in the first example? I cannot think of a good reason to do this.

It simplifies the grammar, immensely.

I know this mainly as a useful macro implementation trick if where you want to be able to use it in an expression.

If the min macro would have worked, it would have allowed the two lines

    min(1, 2, out);
    return out;

to be condensed into one line.

It may not be a good reason to do this, but you can condense

    if (failure) {
        errno = EINVAL;
        return -1;
    }

into

    if (failure)
        return (errno = EINVAL, -1);

In any sane code, you'd have the open and close brackets anyways, so all this code does is trade a few '\n' characters for a few parentheses characters. I'd opt for the former still.

Reply on news.ycombinator.com