macro with variable length of argument

[ethan]

Hi All,

How to write a macro with variable length of argument?
For example, if i need a macro to check return value of printf.

#define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

However, it doesn't work. >_<

Thank you very much.

Ethan

[Emmanuel Delahaye]

ethan wrote on 25/09/05 :

How to write a macro with variable length of argument?
C90 :

#define PRINTF(a) print a

usage :

PRINTF (("Hi, I'm %d\n", 49));
For example, if i need a macro to check return value of printf.

#define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

However, it doesn't work. >_<

It may works with C99. I'm not sure of the syntax...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

[Emmanuel Delahaye]

(supersedes <mn***********************@YOURBRAnoos.fr>)

ethan wrote on 25/09/05 :

How to write a macro with variable length of argument?
C90 :

#define PRINTF(a) printf a

usage :

PRINTF (("Hi, I'm %d\n", 49));
For example, if i need a macro to check return value of printf.

#define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

However, it doesn't work. >_<

It may works with C99. I'm not sure of the syntax...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."

[SM Ryan]

"ethan" <op*****@gmail.com> wrote:
# Hi All,
#
# How to write a macro with variable length of argument?
# For example, if i need a macro to check return value of printf.
#
# #define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

You can do it with double parentheses. (Note no parentheses
after printf.)

@ more t.c
#define PRINTF_ESC(x) if(printf x == 10) goto end;
PRINTF_ESC((a))
PRINTF_ESC((a,b,c,d))

@ cc -E t.c
# 1 "t.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "t.c"

if(printf (a) == 10) goto end;
if(printf (a,b,c,d) == 10) goto end;
I think gcc has an extension for this, but it might not
be available elsewhere.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
OOOOOOOOOO! NAVY SEALS!

[Ulrich Eckhardt]

ethan wrote:

How to write a macro with variable length of argument?
Don't.
For example, if i need a macro to check return value of printf.

Then you write a function doing that, somewhere along these lines:

void foo( char const* fmt, ...)
{
va_list args;
va_start( args, fmt);
if(42 != vprintf( fmt, args))
exit(667);
}

Macros are evil.

Uli

[Charles Mills]

ethan wrote:

Hi All,

How to write a macro with variable length of argument?
For example, if i need a macro to check return value of printf.

#define PRINTF_ESC(x, ...) if(printf(x, ...) == 10) goto end;

However, it doesn't work. >_<

Thank you very much.

Ethan

In C99 you can do the following:

#define PRINTF_ESC(x, ...) if(printf(x, __VA_ARGS__) == 10) goto end;

The only problem with this is that PRINTF_ESC will require two or more
parameters, since the elispses must hold one or more parameters. A
better way to do this would be:

#define PRINTF_ESC(...) if(printf(__VA_ARGS__) == 10) goto end;

FYI: it is bad to use goto's (especially in a macro definition!) and
customary to leave the semicolon off the end of you macro definition or
to do the following:
#define PRINTF_ESC(...) do { if(printf(__VA_ARGS__) == 10) goto end; }
while (0)

Also note that the meaning of the elipses in macro functions is much
different than in real functions and as another poster mentions your
better off using a real function for this (that way you can't use a
goto ;).

Also see http://www.delorie.com/gnu/docs/gcc/cpp_19.html

-Charlie

[Stan Milam]

Ulrich Eckhardt wrote:

Macros are evil.

Uli

Why?

[Skarmander]

Stan Milam wrote:

Ulrich Eckhardt wrote:

Macros are evil.

Why?

If ya hafta ask, ye'll never know!

That said, "macros are evil" is primarily a cry from the C++ camp, see
for example
http://www.parashift.com/c++-faq-lit...s.html#faq-9.5

While preferring inline functions and constants to macros is good
advice, C programmers can't and won't do it. Can't because, before C99
(which will take another, oh, ten years or so to catch on), there was no
standard mechanism for inlining functions, won't because it's a staple
of C culture.

The use of #define for symbolic constants is so ingrained that it will
probably remain part of C until the time_t's wrap around, but luckily
their use is disciplined enough not to cause much trouble... usually.
Ditto on include guards: #ifndef HEADER_H #define HEADER_H... Go beyond
that and it quickly goes downhill.

The preprocessor unlocks power programmers are all too eager to (ab)use.
More than a few times I've stared at a jungle of ALL-CAPS code where
"convenient" macros effectively defined a completely new language
because the perpetrators either loathed typing or apparently believed
that by hiding crud behind macros, it stops being crud. When you have to
tell your compiler to give you the preprocessor output to pore over
because you're tired of chasing include files for the definitions, you
know you're having a bad day.

S.

[SM Ryan]

Ulrich Eckhardt <do******@knuut.de> wrote:
# ethan wrote:
# > How to write a macro with variable length of argument?
#
# Don't.

You can't use goto from one function to another.
You would have to set up a longjmp.

# Then you write a function doing that, somewhere along these lines:
#
# void foo( char const* fmt, ...)
# {
# va_list args;
# va_start( args, fmt);
# if(42 != vprintf( fmt, args))
# exit(667);

It used a goto, not an exit.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
What kind of convenience store do you run here?

[SM Ryan]

Skarmander <in*****@dontmailme.com> wrote:
# Stan Milam wrote:
# > Ulrich Eckhardt wrote:
# >
# >> Macros are evil.
# >>
# >
# > Why?
#
# If ya hafta ask, ye'll never know!

You know, one of the first things people do with an
assembler is to write an evil macro processor.

They do the same evil with shell aliasses.

I wonder why people do these evil things so often?
Naturally evil?

# The use of #define for symbolic constants is so ingrained that it will

I wonder how you would do something like this without #defines
#ifdef __MACHINE1__
#define Sformat "%lld"
#define Tformat "%ld"
#endif
#ifdef __MACHINE2__
#define Sformat "%f"
#define Tformat "%d"
#endif
S x; T y;
priintf("aleph " Sformat " beth " Tformat " gimel\n",S,T);
without having to do a malloc and strcpys.

# that by hiding crud behind macros, it stops being crud. When you have to
# tell your compiler to give you the preprocessor output to pore over
# because you're tired of chasing include files for the definitions, you
# know you're having a bad day.

Testify, brother! I mean I see people using these 'functions'
and the code is off in some other file. And you're constantly
flipping back and forth because the original coder expected me
to understand how to use 'abstractions'.

Can you imagine the nerve of some people?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Why are we here?
whrp

[Ulrich Eckhardt]

Skarmander wrote:

That said, "macros are evil" is primarily a cry from the C++ camp, see
for example
http://www.parashift.com/c++-faq-lit...s.html#faq-9.5
Hmmm, I don't think there is anything that only applies to C++ but several
reasons are given in that FAQ so it could be interesting reading even for
a C programmer. Multiple evaluation of side-effects, the absolute
disrespect for scoping rules, the fact that they can be replaced with
inline functions (in many cases) are those that immediately jump to my
mind.
While preferring inline functions and constants to macros is good
advice, C programmers can't and won't do it. Can't because, before C99
(which will take another, oh, ten years or so to catch on), there was no
standard mechanism for inlining functions, won't because it's a staple
of C culture.
I hope I misunderstand you here, or are you really saying that macro
functions are part of C culture and therefore you are using them even if
there are better alternatives?

Anyhow, I never found a compiler that did not understand inline (yes, a few
of them needed __inline or __inline__, a case where the preprocessor can
be made good use of). I admit I don't do much programming on legacy
systems though, so it might be possible that such compilers still exist.
None of the compilers I did and do C with claimed C99 conformance btw,
except for newer gccs perhaps.
The use of #define for symbolic constants is so ingrained that it will
probably remain part of C until the time_t's wrap around, but luckily
their use is disciplined enough not to cause much trouble... usually.
AFAIK, C has another big problem in that aspect, a constant does not
constitute an 'integral constant expression', i.e. it can't be used
specify the size of an array. I'm rather sure of this for C89, not so sure
about C99.

Hmm, maybe this is the reason you attribute 'macros are evil' to C++ since
in C++ 'inline' is part of the language and constants can be used to
declare arrays, so two possible reasons that you need them are gone.

Ditto on include guards: #ifndef HEADER_H #define HEADER_H... Go beyond
that and it quickly goes downhill.
Those are the best present solution for something that should be a proper
part of the language. It doesn't justify using macros in places where a
better alternative exists.
The preprocessor unlocks power programmers are all too eager to (ab)use.
More than a few times I've stared at a jungle of ALL-CAPS code where
"convenient" macros effectively defined a completely new language
because the perpetrators either loathed typing or apparently believed
that by hiding crud behind macros, it stops being crud. When you have to
tell your compiler to give you the preprocessor output to pore over
because you're tired of chasing include files for the definitions, you
know you're having a bad day.

My heart feels with you. I've been refactoring someone else's code for the
last three weeks and will probably go on with it this week. This code
didn't contain an overabundance of macros but showed a serious
misunderstanding of how to use a typed language and OO design. It's not
even C FWIW.

Uli

[Skarmander]

SM Ryan wrote:

Skarmander <in*****@dontmailme.com> wrote:
# Stan Milam wrote:
# > Ulrich Eckhardt wrote:
# >
# >> Macros are evil.
# >>
# >
# > Why?
#
# If ya hafta ask, ye'll never know!

You know, one of the first things people do with an
assembler is to write an evil macro processor.

They do the same evil with shell aliasses.

I wonder why people do these evil things so often?
Naturally evil?
No, it's because textual replacement is one of the most obvious things a
computer can do. By layering it over a language not based on text
replacement, you get a more powerful language. In fact, you get a *much*
more powerful language. One that is able to transcend the more mundane
considerations of syntax and structure on its lower level.

Assembler and shell constructs are in dire need of this power boost. A
high-level language (even a "high-level assembler" like C) shouldn't be,
it has ways of implementing abstraction itself. At best text replacement
should be used conservatively, where in-language constructs just won't do.
# The use of #define for symbolic constants is so ingrained that it will

I wonder how you would do something like this without #defines
#ifdef __MACHINE1__
#define Sformat "%lld"
#define Tformat "%ld"
#endif
#ifdef __MACHINE2__
#define Sformat "%f"
#define Tformat "%d"
#endif
S x; T y;
priintf("aleph " Sformat " beth " Tformat " gimel\n",S,T);
without having to do a malloc and strcpys.
That's easy, use C++ and overload operator<<.

But less jocularly, yeah, I can't have my cake and eat it too. If you
don't use the preprocessor for conditional compilation in this case, you
can't construct the printf() format string at compile time. You'll
either need to construct the string dynamically or use more printf()
statements (I'd go for the latter, by the way). There goes my whole
argument right there.

Or not. I never said macros are simply not to be used, after all.
# that by hiding crud behind macros, it stops being crud. When you have to
# tell your compiler to give you the preprocessor output to pore over
# because you're tired of chasing include files for the definitions, you
# know you're having a bad day.

Testify, brother! I mean I see people using these 'functions'
and the code is off in some other file. And you're constantly
flipping back and forth because the original coder expected me
to understand how to use 'abstractions'.

Can you imagine the nerve of some people?

Hmm, do I taste the sharp barbs of sarcasm raking over my back there?

There are, of course, a few subtle differences between macros and
functions in the abstraction department, and especially in how clear the
abstraction is, and over how many include files said abstractions have
been scattered, and how much help the compiler offers you in detecting
incorrect use, and the difference between doing something *in* a
language and doing something *with* a language (or dare I say *to* a
language).

But if you think it's more constructive to pretend I'm just not suave
enough to match the amazing powers of abstraction people use when they
give me a list of struct declarations composed entirely of macros, go ahead.

Yes, I *am* making an argument of degree here.

S.

[Skarmander]

Ulrich Eckhardt wrote:

Skarmander wrote: <snip>

While preferring inline functions and constants to macros is good
advice, C programmers can't and won't do it. Can't because, before C99
(which will take another, oh, ten years or so to catch on), there was no
standard mechanism for inlining functions, won't because it's a staple
of C culture.

I hope I misunderstand you here, or are you really saying that macro
functions are part of C culture and therefore you are using them even if
there are better alternatives?

No. I'm saying people in general do this, and that they will also
dispute what's "better".
Anyhow, I never found a compiler that did not understand inline (yes, a few
of them needed __inline or __inline__, a case where the preprocessor can
be made good use of). I admit I don't do much programming on legacy
systems though, so it might be possible that such compilers still exist.
None of the compilers I did and do C with claimed C99 conformance btw,
except for newer gccs perhaps.
The problem I see is that people will reach for the preprocessor first,
and inline (or __inline or __inline__) second, precisely because
everyone knows and loves the preprocessor. This is especially tempting
for those oneliners you *could* turn into a proper function, but don't.

Projects that make heavy use of inlined functions typically do approach
the problem systematically and use a #define (yes!) with INLINE
expanding to whatever keyword is appropriate. (See? Another valid use of
the preprocessor. :-) But most people won't bother with the set-up.

Another common use of the preprocessor is for "generic" functions. You know:

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

Much clearer than writing that silly ternary operator all the time, and
see how it works regardless of type?

Incidentally, this particular macro cost me quite a bit of time to track
down in the header files supplied with Visual Studio, as it caused
compilation of a C++ program that used the max function in the standard
library to fail. I finally found the #define, and the NOMINMAX define
that would turn it off. Joy. (I'm sure they've fixed this problem by
now, but I haven't checked.)

The use of #define for symbolic constants is so ingrained that it will
probably remain part of C until the time_t's wrap around, but luckily
their use is disciplined enough not to cause much trouble... usually.

AFAIK, C has another big problem in that aspect, a constant does not
constitute an 'integral constant expression', i.e. it can't be used
specify the size of an array. I'm rather sure of this for C89, not so sure
about C99.

And exactly because of this sort of confusion, people will prefer to use
a #define where at least they know they'll get a constant number, not
a readonly-but-not-really-a-constant variable they have to declare
"extern" and other bothersome constructs. "const" is a bit of a misnomer.
Hmm, maybe this is the reason you attribute 'macros are evil' to C++ since
in C++ 'inline' is part of the language and constants can be used to
declare arrays, so two possible reasons that you need them are gone.

It did start with C++, when people observed that these constructs made
the language capable of doing a common thing directly, rather than
needing the preprocessor as a crutch. I'm sure quite a few people still
don't get what the fuss is about.

Ditto on include guards: #ifndef HEADER_H #define HEADER_H... Go beyond
that and it quickly goes downhill.

Those are the best present solution for something that should be a proper
part of the language. It doesn't justify using macros in places where a
better alternative exists.

<snip>
Yes, the keyword in all of these things is "where a better alternative
exists". Keep in mind that "better" is also subjective, as per elsewhere
in this thread. If it's very important to you that everything happens at
compile time, for example, you may be required to use macros for things
that could very well be done in the language itself, but that you're
just not willing to pay the cost for.

The include guards problem is part of C's barebones approach to
dependency management, in that it has none, and expects you to pick up
the slack. I'm sure many people actually like *that*, too.

S.

[Mark McIntyre]

On Sun, 25 Sep 2005 21:06:21 +0200, in comp.lang.c , Ulrich Eckhardt
<do******@knuut.de> wrote:

Skarmander wrote:

That said, "macros are evil" is primarily a cry from the C++ camp, see
for example
http://www.parashift.com/c++-faq-lit...s.html#faq-9.5
Hmmm, I don't think there is anything that only applies to C++ but several
reasons are given in that FAQ so it could be interesting reading even for
a C programmer.

My first comment on that site would be that it seems to be written by
someone who dislikes macros, and so its not exactly an impartial
reference. All of his 'evils' can be trivially avoided by the usual
method - learning how to programme the language, instead of assuming
its the same as another one you already know....

More importantly C++ has other ways to do the same thing as #define
whereas the same logic doesn't apply in C. ISTR how const works is an
example.
I hope I misunderstand you here, or are you really saying that macro
functions are part of C culture and therefore you are using them even if
there are better alternatives?
Partly.
Anyhow, I never found a compiler that did not understand inline
I've come across several, but its irrelevant since the C standard
didn't require it to be supported.
AFAIK, C has another big problem in that aspect, a constant does not
constitute an 'integral constant expression',
A constant most certainly can. You're confusing const with constant.
Remember that in C, a const object is not a constant.
Hmm, maybe this is the reason you attribute 'macros are evil' to C++ since
in C++ 'inline' is part of the language and constants can be used to
declare arrays, so two possible reasons that you need them are gone.

Assuming by "constant" you refer to const objects, then you're quite
right. C++, being a different language, has different ways of
achieving the same effect.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Imre Palik]

Stan Milam <st*****@swbell.net> writes:

Ulrich Eckhardt wrote:

Macros are evil.
Uli

Why?

It can make a perfectly good day bad, when you have to figure out why that
damned thing don't compile, and all you did was to #include another file.

For small projects, with a handful of developpers they ar OK, I guess, but
they don't scale well beyond this.

As a rule of thumb, I'd say use them only when you definitely must. I.e.,
you are using __FILE__, __LINE__, etc.; you are using the # or ##; you want
compile-time constants; you are fighting a performance bottleneck with C89
and you need inlining.

ImRe

[Mark McIntyre]

On 26 Sep 2005 08:54:01 +0200, in comp.lang.c , "Imre Palik"
<fi********************@automation.siemens.com> wrote:

<of macros, I think>

For small projects, with a handful of developpers they ar OK, I guess, but
they don't scale well beyond this.
I guess our 2.5 MLOC app, with around 40 developers spread through
three global sites, counts as small then.... :-)
you are fighting a performance bottleneck with C89
and you need inlining.

Performance bottlenecks are defined by QOI not by the Standard.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Imre Palik]

Mark McIntyre <ma**********@spamcop.net> writes:

On 26 Sep 2005 08:54:01 +0200, in comp.lang.c , "Imre Palik"
<fi********************@automation.siemens.com> wrote:

<of macros, I think>

For small projects, with a handful of developpers they ar OK, I guess, but
they don't scale well beyond this.

I guess our 2.5 MLOC app, with around 40 developers spread through
three global sites, counts as small then.... :-)

Possibly. At least I never worked on such a small project before.
(100-500 developpers, 3-4 global sites. I never had the access rights to
count all the LOC ...). Luckily there was almost no macros in the previous
projects I worked on. So I only encountered with my first ever macro name
collision error a couple of weeks before. Interestingly, it was not me,
who wrote the macros. I only happened to include a bunch of headers in
such an order, that the macros within are generated invalid C code.

you are fighting a performance bottleneck with C89
and you need inlining.

Performance bottlenecks are defined by QOI not by the Standard.

Yeah. But the tools one can use to solve them are defined by the
standard. And macros provide guaranteed inlining.

If one can prove (preferably with measurements), that this capability
outweights the danger of using them, then their use is 100% justified.
Otherwise it might hurt somebody somewhat later without any real gain.

ImRe

[Mark McIntyre]

On 27 Sep 2005 12:51:38 +0200, in comp.lang.c , "Imre Palik"
<fi********************@automation.siemens.com> wrote:

(of a mere 2.5 MLOC and 30-40 developer project)

I never worked on such a small project before.
(100-500 developpers, 3-4 global sites.
I suspect its impossible for 100-500 developers to work on a single
project at once. My guess is this is a "project" like MS Office is a
project, or Linux is a project - ie its actually several dozen smaller
but linked projects with shared modules. YMMV of course.
So I only encountered with my first ever macro name
collision error a couple of weeks before.

IME macro name collisions occur because there are no company
standards. If you name macros using some conventions, clashes are
ironed out during code review.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----