Re: style guides on "#undef"

[David Brown]

On 28/06/15 21:19, Stefan Ram wrote:
> guide A:
>
> Don't use macros! OK, (...) treat them as a last resort.
> (...) And #undef them after you've used them, if possible.
>
> guide B:
>
> #undef should not normally be needed. Its use can lead
> to confusion with respect to the existence or meaning of
> a macro when it is used in the code
>

Use guide C - avoid macros unless they really are the clearest and best
way to solve the problem at hand. But don't use #undef except in
/really/ special code, as it leads to confusion - macros should normally
have exactly the same definition at all times in the program, or at
least within the file.

[Alf P. Steinbach]

On 28-Jun-15 9:19 PM, Stefan Ram wrote:
> guide A:
>
> Don't use macros! OK, (...) treat them as a last resort.
> (...) And #undef them after you've used them, if possible.
>
> guide B:
>
> #undef should not normally be needed. Its use can lead
> to confusion with respect to the existence or meaning of
> a macro when it is used in the code
>

Ordinary include guards are incompatible with guide A. Well I could
agree with a preference for #pragma once instead of include guards (and
just don't support any e.g. IBM compiler that doesn't support the
pragma), but /requiring/ that one doesn't use include guards is IMHO to
go too far. It's more work and less clear, but if someone wants to, hey.

As an example that's incompatible with guide B, in Windows desktop
programming one will normally, nowadays, defined UNICODE before
including <windows.h>. The definition doesn't matter, just that it's
defined. But if it is defined in code and there is a previous definition
one will get a sillywarning with e.g. g++ or Visual C++. And a simple
solution is to #undef it, like this:

#undef UNICODE
#define UNICODE
#include <windows.h>

And this is very normal code.

Rules to be mechanically followed are generally not compatible with C++
programming, which requires Some Intelligence Applied™.

Therefore I think that neither guide referred to and quoted above, can
be of very high quality.


Cheers & hth.,

- Alf
[Sorry, yet again I inadvertently applied Google Groups experience and
hit "Reply". I'm currently searching for the "Unsend" button.]

--
Using Thunderbird as Usenet client, Eternal September as NNTP server.

[Öö Tiib]

On Sunday, 28 June 2015 22:19:56 UTC+3, Stefan Ram wrote:
> guide A:
>
> Don't use macros! OK, (...) treat them as a last resort.
> (...) And #undef them after you've used them, if possible.
>
> guide B:
>
> #undef should not normally be needed. Its use can lead
> to confusion with respect to the existence or meaning of
> a macro when it is used in the code

I use macros for things that are impossible without macros.
These are mostly things for better runtime debug diagnostics or
traces.
Examples:
I can't optionally use compiler-specific extensions without macros.
I can't get current source code file name, function name, line number
or compiling time without macros.
I can't both stringize and evaluate part of code without macros.

Otherwise I avoid macros. The ones that I use I define in general
configuration header that is included everywhere and I never #undef any
of those.

[Öö Tiib]

On Sunday, 28 June 2015 23:24:36 UTC+3, Alf P. Steinbach wrote:
> Well I could
> agree with a preference for #pragma once instead of include guards (and
> just don't support any e.g. IBM compiler that doesn't support the
> pragma), but /requiring/ that one doesn't use include guards is IMHO to
> go too far.

IBM XL C/C++ certainly supports pragma once. AFAIK only Oracle Solaris
Studio does not support it from C++ compilers still under active
maintenance.
Forbidding include guards is still perhaps going too far with style
guide.

[Juha Nieminen]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> guide A:
>
> Don't use macros! OK, (...) treat them as a last resort.
> (...) And #undef them after you've used them, if possible.

There are things that can only be done with preprocessor macros.
assert() is the ubiquitous example. (And obviously you shouldn't
be #undeffing assert().)

(The reason why assert() can only be done with a macro is that it
prints the file and line where the assertion failure happened,
which is impossible in C++ proper.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Alf P. Steinbach]

On 29-Jun-15 10:18 AM, Juha Nieminen wrote:
> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> guide A:
>>
>> Don't use macros! OK, (...) treat them as a last resort.
>> (...) And #undef them after you've used them, if possible.
>
> There are things that can only be done with preprocessor macros.
> assert() is the ubiquitous example. (And obviously you shouldn't
> be #undeffing assert().)

Also it would be unwise to #undef "errno" after use...

(C++14 §19.4/1 "errno shall be defined as a macro")


* * *

Regarding the associated issue of use of #undef in general for standard
macros, i.e. whether that's acceptable, there's the NDEBUG macro.

C++14 §17.6.2.2/2 "the effect of including either <cassert> or
<assert.h> depends each time on the lexically current definition of NDEBUG."

The dependency is each time on the existence of NDEBUG, not on any
particular definition.

And that does not make sense if NDEBUG is never #undef-ed.

So this is one case where the standard assumes and depends on client
code use of #undef for a standard macro, and I mention it as an example
that that's not always an abomination. In another posting I mentioned
another concrete example, that of using #undef to avoid warnings for a
following #define of UNICODE in Windows desktop programming. However,
UNICODE is only a de facto standard, not part of the C++ standard.


Cheers,

- Alf

[Rosario19]

On 28 Jun 2015 19:19:46 GMT, (Stefan Ram) wrote:

> guide A:
>
> Don't use macros! OK, (...) treat them as a last resort.
> (...) And #undef them after you've used them, if possible.
>

> guide B:
>
> #undef should not normally be needed. Its use can lead
> to confusion with respect to the existence or meaning of
> a macro when it is used in the code

local macro

int f(void)
{
#define a b
#define c d
#define g h

....

#undef g
#undef c
#undef a

return 0;

}

[David Harmon]

On Mon, 29 Jun 2015 08:18:03 +0000 (UTC) in comp.lang.c++, Juha Nieminen
<nos...@thanks.invalid> wrote,

>There are things that can only be done with preprocessor macros.
>assert() is the ubiquitous example. (And obviously you shouldn't
>be #undeffing assert().)

Of course not. You #undef NDEBUG and #include <assert.h> again.

[Richard]

[Please do not mail me a copy of your followup]

David Brown <david...@hesbynett.no> spake the secret code
<mmpj9u$tla$2...@dont-email.me> thusly:

>Use guide C - avoid macros unless they really are the clearest and best
>way to solve the problem at hand. But don't use #undef except in
>/really/ special code, as it leads to confusion - macros should normally
>have exactly the same definition at all times in the program, or at
>least within the file.

I have used macros to eliminate some boilerplate when constructing a
table of values. (This was pre-std::initializer_list and {}
construction, so if I were do that code again today I might not need a
macro at all.) This is the only time I've used #undef -- once that
table is defined, then I *don't* want anyone to use the macro anymore
and therefore I #undef it. Since the table is defining data, this was
in the context of a source file, not a header file. The macro had an
intention revealing name, so it is unlikely that anyone would be using
a macro of the same name, but different meaning, elsewhere in the code.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>