473,326 Members | 2,147 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

MACROs are ugly but...

....in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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-+-
Oct 6 '05 #1
11 2805

Ben Hetland wrote:
...in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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-+-


How about putting the "dirtywork" in a separate header, and doing this:

#if defined(DO_DIRTYWORK)
#include "dirtywork.h"
#endif

Then have your pragmas and whatnot in your dirtywork.h...

-David

Oct 6 '05 #2
[cross-posting removed]

On 6 Oct 2005 07:06:30 -0700, "David Resnick" <ln********@gmail.com>
wrote:

Ben Hetland wrote:
...in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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-+-


How about putting the "dirtywork" in a separate header, and doing this:

#if defined(DO_DIRTYWORK)
#include "dirtywork.h"
#endif

Then have your pragmas and whatnot in your dirtywork.h...

-David


This is a pretty good solution for configuration macros which are
defined for an entire project, or for a big part of one.

Unfortunately, it isn't quite as easy as that. Often one would want to
wrap only single functions, or perhaps the contents of a single source
file (not a header!) between #pragma warning (disable ... ) and
#pragma warning ( default ... ) or something similar. This would
require at least two separate header files, and I think the
maintenance involved would be greater than just typing in the
pragma's.

IMHO one should only put such things into separate files which need to
be accessed by more than one source file. One would hardly wish to
turn off specific warnings for an entire project, although there are
certainly enough programmers who would argue otherwise. I, for one, am
only happy when my code compiles without any warnings at all. If there
is a certain warning I cannot work around, then I will turn it off
only for whatever portion of code causes the warning and document the
place well as to why it should be turned off. Typing the #pragma or
whatever directly into the source enforces the idiom that they are
extremely local, and that there is a strong dependency between them
and the code they influence.

At any rate, commonly-used #pragmas can easily be stored as templates
in most modern-day IDE's to save typing.

--
Bob Hairgrove
No**********@Home.com
Oct 6 '05 #3

Ben Hetland wrote:
...in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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?


You should be able to use the _Pragma preprocessor operator to create
#pragma directives using macros. _Pragma is part of the C99 standard
and I am unsure of its current status in C++. But many C++ compilers
implement it.

Greg

Oct 6 '05 #4
David Resnick wrote:
How about putting the "dirtywork" in a separate header, and doing this:

#if defined(DO_DIRTYWORK)
#include "dirtywork.h"
#endif


Yes, that might work, but means 3 lines of code for every single of
these places that I need this thing. I think that is just contributing
more to "polluting" the general code structure/algorithm wherever it's
used. BTW, if it's only the one pragma, then it could also be achieved
without the extra include by writing

#pragma ( disable ... )
DO_DIRTYWORK
#pragma ( default ... )

everywhere. IMHO, it's still a bit too messy.
(However, the real-life case had more than that...)

I guess I cannot even put it all into an include file, and have the
macro #include that, because of the # again...

--
-+-Ben-+-
Oct 6 '05 #5
Ben Hetland wrote:
...in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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-+-


A small criticism: if possible, it would be better to save and restore
the state of the warnings rather than set them to the default since the
warnings may have already enabled or disabled explicitly elsewhere.
With VC++ this can be done with something like this:

#pragma warning(push)
#pragma warning(disable:4995)
// Code that generates 4995 goes here
#pragma warning(pop)

Cheers! --M

Oct 6 '05 #6


Ben Hetland wrote On 10/06/05 09:59,:
...in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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.
#pragma looks like a preprocessor directive, and the C
Standard describes it in the preprocessor section. If you
think about it, though, it's immediately clear that most
#pragmas are not "really" preprocessor constructs, because
their effect is felt long after the preprocessor has been
and gone. A #pragma that adjusts struct padding or controls
the aggressiveness of the optimizer's loop unrolling has
nothing to do with the preprocessor and everything to do
with code generation.

The point of all this is that the way #pragma is handled
may very well differ between C and C++. Since my knowledge
of C++ wouldn't even earn me a D- I'll answer only for C;
someone else may be able to help you with That Other Language.
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).
The real reason this doesn't work is that expanding
a macro never produces a preprocessor directive, not even
if the expansion happens to resemble one. (6.10.3.4/3)
Can something like that be achieved?
How?


If your compiler supports the latest "C99" Standard, you
can use the _Pragma operator (6.10.9):

#define DO_DIRTYWORK \
_Pragma("warning( disable : 4995 )") \
dirty_little_doings_going_on \
_Pragma("warning( default : 4995 )")

Failing that, the best I can suggest is to put the
dirty work in a separate function, and have DO_DIRTYWORK
generate a call to it.

--
Er*********@sun.com

Oct 6 '05 #7
* Ben Hetland:
...in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive 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.
Your abstraction of your proposed _solution_ of the problem is only
preprocessor-related, but whether problem is, is another question.

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 */
-------------------------------------


Macros can't 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.

E.g., you can put the usage of a deprecated function in its own module (header
plus implementation), by wrapping it in a similar function, and put the
#pragma -- which in general should be enclosed in #ifdef...#endif compiler
version checking -- at the top of the implementation file.

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

Which not only can make the client code more clear, but means you only have to
change _one_ place when that deprecated function is actually removed.

--
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?
Oct 6 '05 #8
In article <43**************@sintef.no>,
Ben Hetland <be***********@sintef.no> wrote:
David Resnick wrote:
#if defined(DO_DIRTYWORK)
#include "dirtywork.h"
#endif

Yes, that might work, but means 3 lines of code for every single of
these places that I need this thing.


Just

#include "dirtywork.h"

and it will have within it the DO_DIRTYWORK conditional test
and the dirty code.
--
Chocolate is "more than a food but less than a drug" -- RJ Huxtable
Oct 6 '05 #9
> Ben Hetlandwrote:
The point was of course to use that DO_DIRTYWORK several places
around
the sources.


Why not having dirtywork in a separated function and then call it
whenever you need to?
Sent via Archivaty.com
Oct 6 '05 #10
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-+-
Oct 7 '05 #11
* 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?
Oct 7 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

37
by: michele.simionato | last post by:
Paul Rubin wrote: > How about macros? Some pretty horrible things have been done in C > programs with the C preprocessor. But there's a movememnt afloat to > add hygienic macros to Python. Got any...
8
by: Michael Winter | last post by:
In a recent post ("About C error" by Victor, 21 Sep 2003), comments were made about the poster's use of macros. What I would like to know is why they are considered bad? I'm not referring to...
37
by: seberino | last post by:
I've been reading the beloved Paul Graham's "Hackers and Painters". He claims he developed a web app at light speed using Lisp and lots of macros. It got me curious if Lisp is inherently faster...
12
by: Steven T. Hatton | last post by:
I've noticed in different places where people who write #MACROS use a null do/while. For example: do { POINTER = new CONSTRUCTOR; \ if (POINTER == 0) { errno = ENOMEM; ACE_THROW_INT...
6
by: David Pokorny | last post by:
Hi, Just wondering if anyone has considered macros for Python. I have one good use case. In "R", the statistical programming language, you can multiply matrices with A %*% B (A*B corresponds to...
3
by: Stephen Sprunk | last post by:
On a project I'm working on, I ran across the following macros: /* assume s is struct stream *, s->p is char, v is unit16_t or uint32_t */ #define in_uint16_le(s,v) { v = *((s)->p++); v +=...
9
by: Ben Hetland | last post by:
....in certain cituations they can be useful if not for anything else, then at least for saving a lot of repetetetetetitititive typing. :-) Beyond the point of "do something better instead", I'm...
4
by: Chronologic | last post by:
All, I have an issue I would like some expert help on. I understand, or so I believe, that C# does not support the concept of a "compile time macro". At least not in the sense I'm looking...
5
by: Alexander Adam | last post by:
Hi! I've got an issue. I have more or less an internal class model for which I want to write various bindings e.g. for Windows COM. Now I've figured to make my internal classes based on...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.