A silly belief shattered (happily)

[Alf P. Steinbach]

For as long as I can remember I have, incorrectly, believed that

MACRO ( whatever )

would not be a valid macro invocation.

Of course the space before "(" wreaks havoc with a macro-with-args /definition/,
and that may be where I got the impression from.

Anyway, with the space allowed much is simplified...


Cheers,

- Alf (amazed at the macro trickery in Boost Preprocessor)

 

[Vladimir Jovic]

For as long as I can remember I have, incorrectly, believed that

MACRO ( whatever )

would not be a valid macro invocation.

Of course the space before "(" wreaks havoc with a macro-with-args
/definition/, and that may be where I got the impression from.

Anyway, with the space allowed much is simplified...

For example?

 

[Alf P. Steinbach]

* Vladimir Jovic:

For example?

#define FIRST( a, b, c ) a

#define BLAHBLAH( tuple ) FIRST tuple

int main()
{
BLAHBLAH( (42, 41, 43) ); // 42
}


Cheers,

- Alf

 

[Vladimir Jovic]

* Vladimir Jovic:

#define FIRST( a, b, c ) a

#define BLAHBLAH( tuple ) FIRST tuple

int main()
{
BLAHBLAH( (42, 41, 43) ); // 42
}

Ok, so this:
BLAHBLAH ( 42, 41, 43 ); // 42
is causing a compilation error, but this:
BLAHBLAH ( (42, 41, 43) ); // 42
is not.

Is that what you are saying?

 

[Ian Collins]

Ok, so this:
BLAHBLAH ( 42, 41, 43 ); // 42
is causing a compilation error, but this:
BLAHBLAH ( (42, 41, 43) ); // 42
is not.

Is that what you are saying?

The key is

FIRST (42, 41, 43)

works.

 

[Alf P. Steinbach]

* Vladimir Jovic:

Ok, so this:
BLAHBLAH ( 42, 41, 43 ); // 42
is causing a compilation error, but this:
BLAHBLAH ( (42, 41, 43) ); // 42
is not.

Is that what you are saying?

No, I'm saying that because the space is allowed one can easily let macros
produce other macro invocations, where the name of the macro to be invoked is a
parameter (otherwise, token-pasting via ## doesn't produce a valid token).

I've not done much macro stuff (obviously!).

But now I need some facility to simplify some notation, and I'm amazed at what's
possible using just the primitive C and C++ preprocessor.


Cheers,

- Alf

 

[Puppet_Sock]

No, I'm saying that because the space is allowed one can easily let macros
produce other macro invocations, where the name of the macro to be invoked is a
parameter (otherwise, token-pasting via ## doesn't produce a valid token)..

Um. If I was in a code review, and I found such
a thing, I'd flag it as a code fault even if it
did "work."

I've not done much macro stuff (obviously!).

This is a *good* thing.

But now I need some facility to simplify some notation, and I'm amazed at what's
possible using just the primitive C and C++ preprocessor.

I think there are better ways to simplify notation
than using macros the way you describe.

Indeed, I'm not real sure I'd say that this scheme
is aptly described as "simplifying" notation.
Socks

 

[Alf P. Steinbach]

* Puppet_Sock:

Um. If I was in a code review, and I found such
a thing, I'd flag it as a code fault even if it
did "work."

You'd have to flag the Boost Preprocessor library as a "code fault", then. ;-)

So as a general statement it makes no sense, but it depends on the context.

For example, in a sweatshop-like workplace it can make sense to impose literal
rules, because the grunt workers are just robots, or would be if such existed.
In other contexts the programmer's job is to apply intelligence and aesthetics,
something that robots following mechanical code-production rules would find
difficult or impossible to do. The application of intelligence and aestethics
can't be judged by literal rules, or rather, should ideally not be so judged,
for doing that will in most cases lower quality instead of raising it (the few
cases where it might raise quality being those where the rules are
coincidentally "right" *and* the programmer had a lapse of judgment).

This is a *good* thing.

I think I agree.

I think there are better ways to simplify notation
than using macros the way you describe.

Indeed, I'm not real sure I'd say that this scheme
is aptly described as "simplifying" notation.

It's good that you write you're not "real sure", since you don't know anything
about "this scheme".


Cheers & hth.,

- Alf