inline vs macro

[junky_fellow]

hi guys,

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

thanks for any help in advance ...

[sam_cit]

ju**********@yahoo.co.in wrote:

hi guys,

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

thanks for any help in advance ...

You could refer to the following link,

http://groups.google.co.in/group/com...13a697/?hl=en#

And inline functions are much better than Macro, which you will
understand if you look at the examples in the above thread.

[jacob navia]

ju**********@yahoo.co.in a écrit :

hi guys,

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

thanks for any help in advance ...

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

Defining an inline function(s) for that would be
quite difficult...

The same for min(a,b)

Other "advantages" of macros is that they can capture
local variables in the calling function:

#define myhack(a) (a+sqrt(var))

void fn(double var)
{
int a;

...
myhack(a);
...
}

You see? The argument var is implicitely passed
to the macro.

On the other hand:

An advantage of inline functions is that they
do not capture local variables in the calling
function:

inline double myhack(int a)
{
return a+sqrt(var);
// This "var" refers to a global variable var,
// NOT to a local variable. This avoids
// UNINTENTIONAL problems with local
// variables
}

[Stephen Sprunk]

<ju**********@yahoo.co.inwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ?

An inline function has type safety and doesn't suffer from
double-evaluation problems.

A macro has type generic-ness and can modify its arguments.

Only one of them may meet your needs in particular cases, though in the
simplest examples they may both work equally well.

Is there any case where using a macro will be more efficient as
compared to inline function ?

If you can replace one with the other and preserve the caller's syntax,
there is no reason to expect one to be more efficient than the other. A
compiler should treat them the same.

Sometimes you can't replace a macro, though. Consider:

#define INC(x) (x++)

A function simply can't do the same thing. You'd have to change callers
from this:

int x=0;
INC(x);

to:

int x=0;
x = inc(x); /* assumes int inc(x) { return x+1; } */

You might also be calling the macro with varying type arguments; there
is no way to write an inline function to replace INC() above that can
handle both doubles and ints correctly.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Fred Kleinschmidt]

<ju**********@yahoo.co.inwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

hi guys,

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

thanks for any help in advance ...

#define MAXOF(x,y) ((x)>(y)?(x):(y))

This macro can be used for short, int, long, float, double, or any
combination of them. To use a function would require
defining many separate functions.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

[Richard Heathfield]

sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Torek]

In article <11*********************@f1g2000cwa.googlegroups.c om>
ju**********@yahoo.co.in <ju**********@yahoo.co.inwrote:

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa?

The advantage of a macro is that it simply performs textual
substitution.

The disadvantage of a macro is that it simply performs textual
substitution.

Besides the other examples posted so far, macros also have access
to the preprocessor's "#" and "##" operators:

#define DEBUG_INTEGER(var) fprintf(stderr, "DEBUG: " #var " = %d\n", var)
#define DEBUG_STRING(var) fprintf(stderr, "DEBUG: " #var " = %s\n", var)
void foo(void) {
int zorg, blaggle;
char *graump;
...
DEBUG_INTEGER(zorg);
DEBUG_INTEGER(blaggle);
DEBUG_STRING(graump);
...
}
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

ju**********@yahoo.co.in a écrit :

>hi guys,
Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?
thanks for any help in advance ...

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

Defining an inline function(s) for that would be
quite difficult...

[...]

Surely you mean:

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

(with an added comment warning that one of the arguments will be
evaluated twice).

One disadvantage of inline functions is that some compilers may not
support them, or may not support them correctly. Yes, they're defined
in C99, the One True Standard for the C programming language, but C99
is not universally implemented.

--
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.

[dcorbit]

Richard Heathfield wrote:

sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation
Type safety
Less prone to undefined behavior

A function macro offers something for the lazy programmer:
A poor man's C++ template in C ... Make that a destitute man's C++
somewhat template like thingy in C. Except that they are universally
broken.

But the ability to apply that macro to any argument is one of its
largest downfalls.

In short, function macros are the result of hazardous laziness. There
is not one single instance where the correct functions would not be
superior. If your compiler does not support inline functions, it is
time to get a new compiler. If no compiler is available for your
toaster IC, then just write the code inline instead of using macros.
Because hey, who likes burnt toast in the morning.

If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers. They are not as bad as gets(), but still
completely awful.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

dc*****@connx.com said:

>
Richard Heathfield wrote:

>sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at the
expense of stopping them doing clever things, too. Doug Gwyn once said
something of the kind.

<snip>

If your compiler does not support inline functions, it is
time to get a new compiler.

It's not for us to tell people what compilers to use.

If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
granted. Not only have I removed min and max from the standard library
headers for you, but I have applied this change retroactively, so that it
shall be as if they had *never* been part of the standard library headers.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[dcorbit]

Richard Heathfield wrote:

dc*****@connx.com said:

Richard Heathfield wrote:

sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

Have you ever heard of the Arianne failure? Type safety.

Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at the
expense of stopping them doing clever things, too. Doug Gwyn once said
something of the kind.

I would stop them from using gets().
I would remove function macros from the language.
Neither feature has any merit, considering that alternatives exist
which are superior in every way.

<snip>

If your compiler does not support inline functions, it is
time to get a new compiler.

It's not for us to tell people what compilers to use.

It's not an order. It's advice.

If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
granted. Not only have I removed min and max from the standard library
headers for you, but I have applied this change retroactively, so that it
shall be as if they had *never* been part of the standard library headers.

Right, that's C++ with the header defect. Lots of C compilers mimic
it, though.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jaysome]

On Wed, 20 Dec 2006 07:13:29 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>dc*****@connx.com said:

>>
Richard Heathfield wrote:

>>sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

Why would you ever want side effects?

>Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

Why would you ever NOT want type safety?

>Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at the
expense of stopping them doing clever things, too. Doug Gwyn once said
something of the kind.

Possibly.

><snip>

>If your compiler does not support inline functions, it is
time to get a new compiler.

It's not for us to tell people what compilers to use.

>If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
granted. Not only have I removed min and max from the standard library
headers for you, but I have applied this change retroactively, so that it
shall be as if they had *never* been part of the standard library headers.

I just looked, and neither of my two hard-copies of the Schildt book
nor my PDF version of the standard mention anything about macros named
"min" or "max" now. I'm sure no one other than me has touched the
books in the past few days; and the modification date of the PDF file
didn't even change. How could that be?

Happy Holidays
--
jay

[Richard Heathfield]

dc*****@connx.com said:

>
Richard Heathfield wrote:

>dc*****@connx.com said:

>
Richard Heathfield wrote:
sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want
the side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

So you're saying macros can't be used safely because you can pass them
stupid arguments? Well, by the same token, functions that take parameters
can't be used safely because it is possible to pass stupid arguments to
them.

Type safety

That can be a good thing or a bad thing, depending on whether you want
the type safety.

Have you ever heard of the Arianne failure? Type safety.

Have you ever heard of the Therac-25 failure? One of the principal causes of
this failure was software re-use. So let's stop re-using software. Or
perhaps we can stop making sweeping generalisations instead.

Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at
the expense of stopping them doing clever things, too. Doug Gwyn once
said something of the kind.

I would stop them from using gets().

Sure. It has no safe use.

I would remove function macros from the language.

But these *do* have a safe use.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

jaysome said:

Richard Heathfield wrote:

>>dc*****@connx.com said:

>>Richard Heathfield wrote:
sa*****@yahoo.co.in said:
<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

Why would you ever want side effects?

Here's an example of a side effect that you want:

int n = printf("Hello, world.\n");
This line sets n to 14. As a side-effect, it displays "Hello, world.\n" on
the standard output device. Side effects can be quite handy.

>

>>Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

Why would you ever NOT want type safety?

Sometimes it gets in the way. That's why void * exists.

<snip>

>>

>>If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish
[is
granted. Not only have I removed min and max from the standard library
headers for you, but I have applied this change retroactively, so that it
shall be as if they had *never* been part of the standard library headers.

I just looked, and neither of my two hard-copies of the Schildt book
nor my PDF version of the standard mention anything about macros named
"min" or "max" now. I'm sure no one other than me has touched the
books in the past few days; and the modification date of the PDF file
didn't even change.

See? It worked!

How could that be?

Magic!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

dc*****@connx.com wrote:

>
I would stop them from using gets().
I would remove function macros from the language.
Neither feature has any merit, considering that alternatives exist
which are superior in every way.

Function macros have one - access to __FILE__ and __LINE__ and ## for
error logging.

--
Ian Collins.

[CBFalconer]

dc*****@connx.com wrote:

>

.... snip ...

>
If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers. They are not as bad as gets(), but
still completely awful.

AFAICS they are (not present). They only show up as examples of
defines.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[dcorbit]

ju**********@yahoo.co.in wrote:

hi guys,

Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

thanks for any help in advance ...

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <float.h>

#define MAX(a,b) ((a) (b) ? (a) : (b))

int main(void)
{
size_t a,
b,
c;
char *s0,
*s1,
*s2;
long long d = LLONG_MAX;
float g = FLT_MAX;
a = 1;
b = 2;
c = MAX(++b, ++a);
s0 = "My name is Skinner The Grinner.";
s1 = "I am a foo bird but I can't fly";
s2 = MAX(s1, s0);
a = MAX(d, g);
printf("here are my MAX things:c=%u,s2=%s,a=%.0f\n", (unsigned)c,
s2, (double) a);
return 0;
}

[dcorbit]

Richard Heathfield wrote:

dc*****@connx.com said:

Richard Heathfield wrote:

dc*****@connx.com said:


Richard Heathfield wrote:
sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want
the side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

So you're saying macros can't be used safely because you can pass them
stupid arguments? Well, by the same token, functions that take parameters
can't be used safely because it is possible to pass stupid arguments to
them.

No. I am saying that you do not know if MAX(a,b) is a macro or a
function unless you examine the implementation.

MAX(++a,++b) is prefectly fine if it is a function and we do not know
if it is OK if it is a macro.

The arguments are stupid if it is a macro and not stupid if it is a
function. But you cannot tell which is which unless you see the actual
definition. In a ten million line C project, will you know for sure
which things are macros and which things are functions?
By their very nature, function macros are defective and cause defects.

Type safety

That can be a good thing or a bad thing, depending on whether you want
the type safety.

Have you ever heard of the Arianne failure? Type safety.

Have you ever heard of the Therac-25 failure? One of the principal causes of
this failure was software re-use. So let's stop re-using software. Or
perhaps we can stop making sweeping generalisations instead.

Reusing bad software is worse than not reusing it.

Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at
the expense of stopping them doing clever things, too. Doug Gwyn once
said something of the kind.

I would stop them from using gets().

Sure. It has no safe use.

Wrong. It is used safely when you never input more bytes than the size
of the object.
In a similar way, function macros are fatally flawed. They can be used
safely, but normal use is not safe.

I would remove function macros from the language.

But these *do* have a safe use.

Just like gets() -- only with extreme care.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

dc*****@connx.com wrote:

Richard Heathfield wrote:

>dc*****@connx.com said:

.... snip ...

>>

>>If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann,
your wish is granted. Not only have I removed min and max from
the standard library headers for you, but I have applied this
change retroactively, so that it shall be as if they had *never*
been part of the standard library headers.

Right, that's C++ with the header defect. Lots of C compilers
mimic it, though.

No, that's the C standard. Any ISO C standard, new or old. Just
thank Richard for satisfying your every wish. Ain't alternate
universes grand.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[jaysome]

On Wed, 20 Dec 2006 08:09:07 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>jaysome said:

>Richard Heathfield wrote:

>>>dc*****@connx.com said:
Richard Heathfield wrote:
sa*****@yahoo.co.in said:
<snip>
>
And inline functions are much better than Macro
>
Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

Why would you ever want side effects?

Here's an example of a side effect that you want:

int n = printf("Hello, world.\n");
This line sets n to 14. As a side-effect, it displays "Hello, world.\n" on
the standard output device. Side effects can be quite handy.

Of course.

What I meant was: "Why would you ever want side effects in macros?".

Your example could easily be extended, to help answer that question.

#define SQUARED(x) (int)((x)*(x))
int k = SQUARED(printf("Hello, world.\n"));

But, what I suspect that Dann meant, was: "Lack of *undesired* side
effects due to multiple evaluation"; something like this:

#define ABS(x) ((x) < 0 ? -(x) : (x))
... ABS( n++ )

>>>Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

Why would you ever NOT want type safety?

Sometimes it gets in the way. That's why void * exists.

But the standard uses void * safely, doesn't it? Look at malloc()'s
prototype in <stdlib.h>.

Of course, if you use malloc(), then you better:

1. Include the header file <stdlib.h>.
2. Not cast its return value.
3. Check for a return value of NULL.

Barring any undefined behavior, use of void * seems type safe to me.

--
jay

[Richard Heathfield]

dc*****@connx.com said:

Richard Heathfield wrote:

>dc*****@connx.com said:

>
Richard Heathfield wrote:
dc*****@connx.com said:
Richard Heathfield wrote:
sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want
the side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

So you're saying macros can't be used safely because you can pass them
stupid arguments? Well, by the same token, functions that take parameters
can't be used safely because it is possible to pass stupid arguments to
them.

No. I am saying that you do not know if MAX(a,b) is a macro or a
function unless you examine the implementation.

Or read the docs. And if it's a function, you don't know what it does unless
you examine the implementation, or read the docs. So you have to do this
anyway.

MAX(++a,++b) is prefectly fine if it is a function and we do not know
if it is OK if it is a macro.

Sure. So read the docs for MAX.

The arguments are stupid if it is a macro and not stupid if it is a
function. But you cannot tell which is which unless you see the actual
definition. In a ten million line C project, will you know for sure
which things are macros and which things are functions?

Read the documentation. Knowing what it is that you're calling - or being
able to find out - is part of being a programmer.

By their very nature, function macros are defective and cause defects.

No, by their very nature, programmers are defective and cause defects. They
can cause these defects just as devastatingly in functions as they can in
macros. Indeed, more so, since there are more places to hide a function's
source code (the macro's source has to be visible, to a certain extent, or
the preprocessor won't be able to find it - the same cannot be said of a
function).

Type safety

That can be a good thing or a bad thing, depending on whether you want
the type safety.

Have you ever heard of the Arianne failure? Type safety.

Have you ever heard of the Therac-25 failure? One of the principal causes
of this failure was software re-use. So let's stop re-using software. Or
perhaps we can stop making sweeping generalisations instead.

Reusing bad software is worse than not reusing it.

Right. And writing bad macros (or calling good macros in a bad way) is worse
than not writing them. That doesn't mean we can't write good macros, and
call them in a good way.

Less prone to undefined behavior

Perhaps. But if you stop people doing stupid things, it's generally at
the expense of stopping them doing clever things, too. Doug Gwyn once
said something of the kind.

I would stop them from using gets().

Sure. It has no safe use.

Wrong. It is used safely when you never input more bytes than the size
of the object.

Quibbling over use of the word "use". What I mean is that a programmer who
puts a call to gets() into a program is risk-exposing his program and
potentially any computer system on which it is used.

In a similar way, function macros are fatally flawed. They can be used
safely, but normal use is not safe.

I would remove function macros from the language.

But these *do* have a safe use.

Just like gets() -- only with extreme care.

No, gets() has no safe use (see above).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

jaysome said:

<snip>

But, what I suspect that Dann meant, was: "Lack of *undesired* side
effects due to multiple evaluation"; something like this:

#define ABS(x) ((x) < 0 ? -(x) : (x))
... ABS( n++ )

Fine, so don't call it that way.

Barring any undefined behavior, use of void * seems type safe to me.

In other words, if you use it right, void * is fine, and if you don't, it
isn't. Well, gosh. :-)

But surely the whole point of type safety is that the compiler should yell
when you do something type-unsafe, yes?

But the compiler will not yell at this (fragment):

char c = 'A';
char *p = c;
void *q = p;
int *r = q;
*r = INT_MAX;

void * discards type safety.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

Richard Heathfield wrote:

jaysome said:

<snip>

>>But, what I suspect that Dann meant, was: "Lack of *undesired* side
effects due to multiple evaluation"; something like this:

#define ABS(x) ((x) < 0 ? -(x) : (x))
... ABS( n++ )

Fine, so don't call it that way.

>>Barring any undefined behavior, use of void * seems type safe to me.

In other words, if you use it right, void * is fine, and if you don't, it
isn't. Well, gosh. :-)

But surely the whole point of type safety is that the compiler should yell
when you do something type-unsafe, yes?

But the compiler will not yell at this (fragment):

Another good reason for compiling C with a C++ compiler :)

char c = 'A';
char *p = c;

Surely it is obliged to issue a diagnostic here?

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

<snip>

>

> char c = 'A';
char *p = c;

Surely it is obliged to issue a diagnostic here?

Er, make that &c :-)

I originally had c as an array, and changed my mind. Obviously not
thoroughly enough.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jaysome]

On Wed, 20 Dec 2006 09:13:51 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:

>jaysome said:

<snip>

>But, what I suspect that Dann meant, was: "Lack of *undesired* side
effects due to multiple evaluation"; something like this:

#define ABS(x) ((x) < 0 ? -(x) : (x))
... ABS( n++ )

Fine, so don't call it that way.

>Barring any undefined behavior, use of void * seems type safe to me.

In other words, if you use it right, void * is fine, and if you don't, it
isn't. Well, gosh. :-)

But surely the whole point of type safety is that the compiler should yell
when you do something type-unsafe, yes?

But the compiler will not yell at this (fragment):

char c = 'A';
char *p = c;
void *q = p;
int *r = q;
*r = INT_MAX;

void * discards type safety.

After changing:

char *p = c;

to

char *p = &c;

which is what I think you meant, my main "compiler" still yells at me
with this warning:

int *r = q;
Info 826: Suspicious pointer-to-pointer conversion (area too small)

In practice, I'd look at that warning, then at the code, and just tell
my software engineer that that's a do-over, and to see me tomorrow
when she has it fixed :^)

--
jay

[Richard Heathfield]

jaysome said:

<snip>

After changing:

char *p = c;

to

char *p = &c;

which is what I think you meant,

Yes, that's correct.

my main "compiler" still yells at me
with this warning:

int *r = q;
Info 826: Suspicious pointer-to-pointer conversion (area too small)

That's nice. No, really! It's a great diagnostic, which goes above and
beyond the call of duty. But now hide the assignment in a function call (to
a function taking void * as its parameter), put the called function in a
different translation unit, and see if your compiler still manages to pick
it up.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Bos]

dc*****@connx.com wrote:

Richard Heathfield wrote:

So you're saying macros can't be used safely because you can pass them
stupid arguments? Well, by the same token, functions that take parameters
can't be used safely because it is possible to pass stupid arguments to
them.

No. I am saying that you do not know if MAX(a,b) is a macro or a
function unless you examine the implementation.

Or you are able to assume that the programmer knew what he was doing and
uses ALL CAPITALS for macros, and for macros only. That's more or less
standard operating procedure; deviating from it is not a good idea.

MAX(++a,++b) is prefectly fine if it is a function

Technically. Stylistically, it goes against the grain.

By their very nature, function macros are defective and cause defects.

You could say the same thing about variadic functions - and more so
about scanf() - with about as much justification.

Type safety
>>
>That can be a good thing or a bad thing, depending on whether you want
>the type safety.
>
Have you ever heard of the Arianne failure? Type safety.

Assuming you mean Ariane 5, that's not quite a correct description. The
cause of those crashes was an overflow occuring in a conversion of a
64-bit floating point number to a 16-bit integer. That's a bad idea
whether you use macros to do it or inline functions.

Have you ever heard of the Therac-25 failure? One of the principal causes of
this failure was software re-use. So let's stop re-using software. Or
perhaps we can stop making sweeping generalisations instead.

Reusing bad software is worse than not reusing it.

On the older model, the software was not bad. The re-use on an
incompatible model caused the problem.

Less prone to undefined behavior
>>
>Perhaps. But if you stop people doing stupid things, it's generally at
>the expense of stopping them doing clever things, too. Doug Gwyn once
>said something of the kind.
>
I would stop them from using gets().

Sure. It has no safe use.

Wrong. It is used safely when you never input more bytes than the size
of the object.

To do this, however, you will need a safe room, a virgin computer, and
bondage gear. And perfect contgrol over your own typing fingers. (Point
in case: that typo in the previous sentence, introducing a single
character which could have overflown a buffer if it had involved gets(),
was not intentional.)

In a similar way, function macros are fatally flawed. They can be used
safely, but normal use is not safe.

Nonsense. gets() cannot be used safely without taking measures beyond
the ISO C Standard. Macros can be used with perfect safety using ISO C
alone.

Richard

[Richard Heathfield]

Richard Bos said:

dc*****@connx.com wrote:

<snip>

[Therac-25]

>Reusing bad software is worse than not reusing it.

On the older model, the software was not bad. The re-use on an
incompatible model caused the problem.

Take this with a pinch of salt because my data source is Wikipedia, but it
appears at least possible that the software *was* bad, its bugs being
disguised by hardware interlocks on earlier versions of the Therac, which
were not present on the -25.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Random832]

2006-12-20 <11**********************@79g2000cws.googlegroups. com>,
dc*****@connx.com wrote:

>
Richard Heathfield wrote:

>dc*****@connx.com said:

>
Richard Heathfield wrote:
sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

That code is perfectly well-defined. At the end, biggest is 4, bar is 4, and
foo is 2. Nothing unsafe at all. Now, your problem is you assume that
the writer wants bar, and biggest, to be 3 rather than 4. But that's
entirely subjective.

I would remove function macros from the language.
Neither feature has any merit, considering that alternatives exist
which are superior in every way.

"function macros" aren't always used as a function. You could have one
that expands to a list of three things with commas and braces and use it
to help initialize a static struct array. How can inline functions do
that?

[dcorbit]

Richard Heathfield wrote:
[snip]

Right. And writing bad macros (or calling good macros in a bad way) is worse
than not writing them. That doesn't mean we can't write good macros, and
call them in a good way.

You can call function macros in a good way (carefully avoiding side
effects if you examine the full source of the macro) but you cannot
write them in a good way because they completely lack type safety and
do not produce the successful isolation that functions provide since we
pass by value.

There is no such thing as a function macro that is better than the same
thing written as an inline function. Using macros is lazy and stupid.
[snip]

[Richard Heathfield]

dc*****@connx.com said:

Richard Heathfield wrote:
[snip]

>Right. And writing bad macros (or calling good macros in a bad way) is
worse than not writing them. That doesn't mean we can't write good
macros, and call them in a good way.

You can call function macros in a good way (carefully avoiding side
effects if you examine the full source of the macro) but you cannot
write them in a good way because they completely lack type safety and
do not produce the successful isolation that functions provide since we
pass by value.

I disagree. I'm not a huge fan of macros, but there are times when I
consider them to be useful and worthwhile, despite their lack of type
safety.

There is no such thing as a function macro that is better than the same
thing written as an inline function. Using macros is lazy and stupid.

I don't see why it's lazy. It actually takes more effort to write this:

#define BYTE(x) ((x) / CHAR_BIT)
#define BIT(x) ((x) % CHAR_BIT)
#define TEST_BIT(a, b) \
(!!(((a)[BYTE(b)]) & (1 << (BIT(b)))))

than this:

int byte(size_t b)
{
return b / CHAR_BIT;
}

int bit(size_t b)
{
return b % CHAR_BIT;
}

int test_bit(unsigned char *a, size_t b)
{
return !!(a[byte(b)] & (1 << bit(b)));
}

because, even though the latter is longer, it's considerably easier to type.

As for "stupid", well, that's a matter of opinion.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

dc*****@connx.com writes:

Richard Heathfield wrote:

>dc*****@connx.com said:

Richard Heathfield wrote:
sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

Good, the use of all-caps warns the user that it's a macro.

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

It's *possible* to use it unsafely. It's also possible to use it
safely. Part of being a good C programmer is knowing that macros can
cause problems if you invoke them with arguments that have side
effects.

Type safety

That can be a good thing or a bad thing, depending on whether you want the
type safety.

Have you ever heard of the Arianne failure? Type safety.

Yes I have. The major problem IIRC was the re-use of the software
for, I think, the Ariane 4 in the Ariane 5 without re-testing for the
new environment. I'm not sure what that has to do with the current
discussion.

[...]

If I had my way, min(a,b) and max(a,b) would be removed from the
standard library headers.

[F/X: waves magic wand] Since it is the season of gifts, Dann, your wish is
granted. Not only have I removed min and max from the standard library
headers for you, but I have applied this change retroactively, so that it
shall be as if they had *never* been part of the standard library headers.

Right, that's C++ with the header defect. Lots of C compilers mimic
it, though.

<OT>C++ has min() and max() defined via type-safe templates.</OT>

A conforming C implementation cannot declare "min" or "max" in any
standard header.

--
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.

[Keith Thompson]

dc*****@connx.com writes:
[...]

No. I am saying that you do not know if MAX(a,b) is a macro or a
function unless you examine the implementation.

By convention, macro names are in all-caps. This convention is not
universally followed, but I'd certainly assume that MAX() is a macro
-- and if it isn't, I'd complain to the programmer who decided to give
it that name.

MAX(++a,++b) is prefectly fine if it is a function and we do not know
if it is OK if it is a macro.

Right, so the *documentation* had better mention that it's a macro.

--
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.

[dcorbit]

Random832 wrote:

2006-12-20 <11**********************@79g2000cws.googlegroups. com>,
dc*****@connx.com wrote:

Richard Heathfield wrote:

dc*****@connx.com said:


Richard Heathfield wrote:
sa*****@yahoo.co.in said:

<snip>

And inline functions are much better than Macro

Why do you think so? And what do you mean by "better"?

Superior in every way that I can imagine.
Lack of side effects due to multiple evaluation

That can be a good thing or a bad thing, depending on whether you want the
side effects.

#define MAX(a,b) ((a) (b) ? (a) : (b))

unsigned foo = 1;
unsigned bar = 2;

unsigned biggest = MAX(++foo, ++bar);

It does not matter if they want the side effects or not. The side
effects cause a defect due to the nature of macros that prevents them
from being used safely.

That code is perfectly well-defined. At the end, biggest is 4, bar is 4, and
foo is 2. Nothing unsafe at all. Now, your problem is you assume that
the writer wants bar, and biggest, to be 3 rather than 4. But that's
entirely subjective.

In other words, it does not work like a function in this example and
produces 'odd' results.

Because the conditional is a sequence point, that particular one does
not cause undefined behavior, but something as simple as:
#define SQUARE(x) ((x)*(x))
unsigned x = 5;
unsigned y = SQUARE(x++);
does produce undefined behavior.

In each case for those samples provided the macros did something odd.

I would remove function macros from the language.
Neither feature has any merit, considering that alternatives exist
which are superior in every way.

"function macros" aren't always used as a function. You could have one
that expands to a list of three things with commas and braces and use it
to help initialize a static struct array. How can inline functions do
that?

I am not opposed to macros that are not used as functions, unless badly
written.

[Keith Thompson]

dc*****@connx.com writes:

ju**********@yahoo.co.in wrote:

> Can you please suggest that in what cases should a macro be
preferred over inline function and viceversa ? Is there any case where
using a macro will be more efficient as compared to inline function ?

[...]

>
#define MAX(a,b) ((a) (b) ? (a) : (b))

[...]

char *s0,
*s1,
*s2;

[...]

s0 = "My name is Skinner The Grinner.";
s1 = "I am a foo bird but I can't fly";
s2 = MAX(s1, s0);

[...]

This invokes undefined behavior by using the relational operator "<"
on pointers to different objects.

--
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.

[Keith Thompson]

dc*****@connx.com writes:
[...]

There is no such thing as a function macro that is better than the same
thing written as an inline function. Using macros is lazy and stupid.

What if you're using a compiler that doesn't implement inline functions?

--
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.

[dcorbit]

Keith Thompson wrote:

dc*****@connx.com writes:
[...]

There is no such thing as a function macro that is better than the same
thing written as an inline function. Using macros is lazy and stupid.

What if you're using a compiler that doesn't implement inline functions?

1. Upgrade your compiler. GCC is fairly ubiquitous across most
platforms, for instance.
2. Write the inline expressions as actual inline expressions.
3. Suffer the function overhead (probably except for very rare cases
it won't matter).
4. Use function macros and hope for the best.

I will admit to having written and used function macros. That having
been said, it was lazy and stupid of me.

--
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.

[Richard Bos]

dc*****@connx.com wrote:

Keith Thompson wrote:

dc*****@connx.com writes:
[...]

There is no such thing as a function macro that is better than the same
thing written as an inline function. Using macros is lazy and stupid.

What if you're using a compiler that doesn't implement inline functions?

1. Upgrade your compiler. GCC is fairly ubiquitous across most
platforms, for instance.

But not all.

2. Write the inline expressions as actual inline expressions.

Again and again and again? That's bad programming. It is, for starters,
harder to maintain, and easier to make a typo.

4. Use function macros and hope for the best.

Bravo. The most sane solution.

I will admit to having written and used function macros. That having
been said, it was lazy and stupid of me.

*Shrug* I think you're being stupid now, not then.

Richard