MACROs are ugly but...

[Ben Hetland]

....in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetit ititive typing. :-)

Beyond the point of "do something better instead", I'm curious about how
the following syntactical problem can be solved. It should apply equally
to C and C++ as it mainly is a preprocessor-related problem.

I tryed to define something similar to the following example:

-------------------------------------
#define DO_DIRTYWORK \
\
#pragma warning( disable : 4995 ) /* Annoying warning */ \
\
/* Do some dirty work here (that I want to hide) */ \
\
#pragma warning( default : 4995 ) /* Warning reactivated */ \
/* finished dirty part */
-------------------------------------

The point was of course to use that DO_DIRTYWORK several places around
the sources. Its content was not really part of the main logic, but
merely a library workaround that required some lines of code injected
"everywhere ". (When the library was fixed later, then maybe I could just
redefine the DO_DIRTYWORK macro as empty!)

However, this doesn't compile of course, because a prepocessor directive
needs to start as the first non-blank # on a line, which is conflicting
with the macro's end-of-line escapes (the \). Obviously, what I _wanted_
to achieve in this particular case, was to have the actual preprocessor
directives emitted from the preprocessor's first replacement (then
further preprocessed in-place where the actual code is used).

Can something like that be achieved?
How?
--
-+-Ben-+-

[Ben Hetland]

Alf P. Steinbach wrote:

Your abstraction of your proposed _solution_ of the problem is only
preprocessor-related, but whether problem is, is another question.
That is true, and for instance for C++ the problem could also be solved
using templates in combination with macros in a single header-file.
However, I posted the question to challenge my shortcoming with the
preprocessor's syntax rules, of which some useful comments have been
posted I think. I would also like to have something that could work in
both languages.

Macros can't generate macros.
This is not about generating macros, but about using other preprocessor
features within a preprocessor feature itself, like a macro definition is.

However, I've seen a similar thing that comes very close to generating
macros many times. That is when macros are built from other macros, and
the building of those macros relies on conditional compilations (another
preprocessor feature) to decide how the macro is actually composed. And
that could happen in multiple levels of "macro nesting". So at least the
preprocessor can generate macros...

But say that warning 4995, for this compiler (whichever it is), is about using
a deprecated function: then that is the problem, and you can ignore the
proposed solution above and concentrate on the problem.
Yes, the original problem was with one of Microsoft's compilers, as you
probably guessed. And deprecated functions are already isolated to a few
files. I used this only for illustration. The specific problem also
included other pragmas and other preprocessor features like #ifdef, but
I thought that wasn't so important in illustrating my question.

This is a much better solution because it abstracts the use of the deprecated
function.

I definitely agree with much of this, but just would like to comment
that not only functions may be deprecated, but also types for instance
(as can classes in C++). Types often have a tendency to pollute the rest
of the "client code" with its presense far beyond that isolated module.

Also, as happens with functions as well, prototypes usually need to be
included in header files which are again included in the "client code".
Fine, except when a prototype uses a deprecated type, which is when
"pollution" easily occurs.

I guess it is often due to some laziness among us that things like that
happen, because with careful considerations in the first place it must
be possible to avoid that kind of practice. However, it is just a
real-life observation, and it really requires great skill and foresight
to be able to foresee everything that will become deprecated in the
future. Say, which one of us can claim that they will only need to
modify one of their code units completely independently of all other
source code in case of the hypothetical event that (say) 'size_t' would
become deprecated one day?

--
-+-Ben-+-

[Alf P. Steinbach]

* Ben Hetland:

Alf P. Steinbach wrote:

Your abstraction of your proposed _solution_ of the problem is only
preprocessor-related, but whether problem is, is another question.
That is true, and for instance for C++ the problem could also be solved
using templates in combination with macros in a single header-file.
However, I posted the question to challenge my shortcoming with the
preprocessor's syntax rules, of which some useful comments have been
posted I think. I would also like to have something that could work in
both languages.

Cross-posted to clc and clc++, I didn't notice.

Cross-language solutions for C++ and C just mean C.

So I think the original question doesn't belong in clc++, but it's a bit late
to fix that now.

Macros can't generate macros.

This is not about generating macros, but about using other preprocessor
features within a preprocessor feature itself, like a macro definition is.

Yes. Actually what I wrote, as opposed to what I meant, is blatantly false...

However, I've seen a similar thing that comes very close to generating
macros many times. That is when macros are built from other macros, and
the building of those macros relies on conditional compilations (another
preprocessor feature) to decide how the macro is actually composed. And
that could happen in multiple levels of "macro nesting". So at least the
preprocessor can generate macros...
For C++, see the amazing "make the preprocessor jump through hoops and give a
rock n' roll concert" library -- or whatever it should be called -- at
<url: http://boost.org/libs/preprocessor/doc/index.html>.

...
Also, as happens with functions as well, prototypes usually need to be
included in header files which are again included in the "client code".
Fine, except when a prototype uses a deprecated type, which is when
"pollution" easily occurs.

For C++, one known solution to that is the PIMPL a.k.a. "compiler firewall"
a.k.a many other things idiom.
<url: http://www.gotw.ca/gotw/024.htm>.
<url: http://www.gotw.ca/gotw/028.htm>.
<url: http://www.gotw.ca/gotw/059.htm> (where the use of std::auto_ptr for an
incomplete type is incorrect; this is the most infamous example of that, the
one often cited when the topicc pops up, still not fixed!).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?