How can MIN macro without :? be written?

[lovecreatesbea...]

#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

[Ben Pfaff]

"[e-mail]" <lo***************@gmail.comwrites:

#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

Here's an expression, without the obfuscation of a macro:
x * (x < y) + y * !(x < y)
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Ben Pfaff wrote:

"[e-mail]" <lo***************@gmail.comwrites:

#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

Here's an expression, without the obfuscation of a macro:
x * (x < y) + y * !(x < y)

You're assuming that 1 * x == x, and that 0 * x == 0. This is not
necessarily true. For example, in floating point arithmetic, using your
expression with an infinity will result in NaN. For another example, if
x is a pointer, 1 * x and 0 * x are not valid expressions.

[Simon Biber]

[e-mail] wrote:

#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

Yes, it can. I won't give you a solution, but point you in a direction.

Think about what the value of (x)<(y) is. How could you manipulate that
value, to give a value that is x if x is the minimum? How then could you
get y if y is the minimum? How can you combine them together? What
happens if they are the same value?

--
Simon.

[Ben Pfaff]

"Harald van Dijk" <tr*****@gmail.comwrites:

Ben Pfaff wrote:

>"[e-mail]" <lo***************@gmail.comwrites:

#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

Here's an expression, without the obfuscation of a macro:
x * (x < y) + y * !(x < y)

You're assuming that 1 * x == x, and that 0 * x == 0. This is not
necessarily true. For example, in floating point arithmetic, using your
expression with an infinity will result in NaN. For another example, if
x is a pointer, 1 * x and 0 * x are not valid expressions.

I was assuming that x and y are integers. Generally that's what
programmers pass to a MIN macro.

This is another reason to avoid macros: people have more
surprising ways to use them than they do with functions.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[Kenneth Brody]

"[e-mail]" wrote:

>
#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

Is this cheating?

#define MIN(x,y) ( (x)+(y) - MAX(x,y) )

:-)

(Yes, I'm ignoring things like integer overflow, loss of floating point
precision, pointers, and so on.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Keith Thompson]

Kenneth Brody <ke******@spamcop.netwrites:

"[e-mail]" wrote:

#define MIN(x, y) ((x)<(y) ? (x):(y))

Can a version without conditional operator of MIN macro be written?

Is this cheating?

#define MIN(x,y) ( (x)+(y) - MAX(x,y) )

:-)

(Yes, I'm ignoring things like integer overflow, loss of floating point
precision, pointers, and so on.)

Yes, it's cheating, because you're ignoring things like integer
overflow, loss of floating point precision, pointers, and so on.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Serve Laurijssen]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>(Yes, I'm ignoring things like integer overflow, loss of floating point
precision, pointers, and so on.)

Yes, it's cheating, because you're ignoring things like integer
overflow, loss of floating point precision, pointers, and so on.

So every line that does integer calculation ignoring overflow is wrong?

[Ben Pfaff]

"Serve Laurijssen" <se*@n.tkwrites:

So every line that does integer calculation ignoring overflow is wrong?

Yes. Unsigned integers don't overflow (they wrap around), but
signed integer overflow yields undefined behavior. Smart
compilers can depend on the undefinedness of signed integer
overflow for optimization purposes, causing your code to actually
malfunction if an overflow occurs.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell

[Keith Thompson]

"Serve Laurijssen" <se*@n.tkwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

(Yes, I'm ignoring things like integer overflow, loss of floating point
precision, pointers, and so on.)

The above was written by Kenneth Brody <ke******@spamcop.net>.
Please don't snip attribution lines.

Yes, it's cheating, because you're ignoring things like integer
overflow, loss of floating point precision, pointers, and so on.

So every line that does integer calculation ignoring overflow is wrong?

No. The code in question was a MIN macro, presumably intended to be
general-purpose. Ignoring overflow in such cases is a bad idea,
especially since it's easy enough to compute MIN in a way that avoids
overflow altogether. (The most straightforward implementation doesn't
work with operands with side effects -- so don't invoke it with
arguments with side effects.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenneth Brody]

Keith Thompson wrote:

>
Kenneth Brody <ke******@spamcop.netwrites:

"[e-mail]" wrote:

>
#define MIN(x, y) ((x)<(y) ? (x):(y))
>
Can a version without conditional operator of MIN macro be written?

Is this cheating?

#define MIN(x,y) ( (x)+(y) - MAX(x,y) )

:-)

(Yes, I'm ignoring things like integer overflow, loss of floating point
precision, pointers, and so on.)

Yes, it's cheating, because you're ignoring things like integer
overflow, loss of floating point precision, pointers, and so on.

Not to mention the fact that MAX() is probably still written using
the ?: operator.

What happens if you have a circular #define set? For example, if the
MAX() macro were also rewritten as above, referring to MIN()? My C
compiler expands MIN() by expanding MAX(), but leaving MAX's MIN()
intact. And MAX() expands MIN(), leaving its MAX() intact.

That is:

given:

#define MAX(x,y) ( (x)+(y) - MIN(x,y) )
#define MIN(x,y) ( (x)+(y) - MAX(x,y) )

then:

MIN(x,y)

expands to:

( (x)+(y) - ( (x)+(y) - MIN(x,y) ) )

Is this defined by the standard as such?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Ben Pfaff]

Kenneth Brody <ke******@spamcop.netwrites:

What happens if you have a circular #define set? For example, if the
MAX() macro were also rewritten as above, referring to MIN()? My C
compiler expands MIN() by expanding MAX(), but leaving MAX's MIN()
intact. And MAX() expands MIN(), leaving its MAX() intact.

From C99 6.10.3.4 (similar text is in C90):

If the name of the macro being replaced is found during this
scan of the replacement list (not including the rest of the
source file's preprocessing tokens), it is not replaced.
Furthermore, if any nested replacements encounter the name
of the macro being replaced, it is not replaced. These
nonreplaced macro name preprocessing tokens are no longer
available for further replacement even if they are later
(re)examined in contexts in which that macro name
preprocessing token would otherwise have been replaced.

--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms