MACROs are ugly but...

Discussion in 'C Programming' started by Ben Hetland, Oct 6, 2005.

  1. Ben Hetland

    Ben Hetland Guest

    ....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-+-
     
    Ben Hetland, Oct 6, 2005
    #1
    1. Advertising

  2. 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
     
    David Resnick, Oct 6, 2005
    #2
    1. Advertising

  3. Ben Hetland

    Greg Guest

    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
     
    Greg, Oct 6, 2005
    #3
  4. Ben Hetland

    Ben Hetland Guest

    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-+-
     
    Ben Hetland, Oct 6, 2005
    #4
  5. Ben Hetland

    mlimber Guest

    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
     
    mlimber, Oct 6, 2005
    #5
  6. Ben Hetland

    Eric Sosman Guest

    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.

    --
     
    Eric Sosman, Oct 6, 2005
    #6
  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?
     
    Alf P. Steinbach, Oct 6, 2005
    #7
  8. In article <>,
    Ben Hetland <> 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
     
    Walter Roberson, Oct 6, 2005
    #8
  9. Ben Hetland

    Ben Hetland Guest

    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-+-
     
    Ben Hetland, Oct 7, 2005
    #9
  10. * 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?
     
    Alf P. Steinbach, Oct 7, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    80
    Views:
    2,451
    Stephen J. Bevan
    Nov 7, 2003
  2. Replies:
    1
    Views:
    463
    Marco Antoniotti
    Oct 7, 2003
  3. Replies:
    5
    Views:
    505
  4. Michael T. Babcock

    Re: Explanation of macros; Haskell macros

    Michael T. Babcock, Nov 3, 2003, in forum: Python
    Replies:
    0
    Views:
    530
    Michael T. Babcock
    Nov 3, 2003
  5. Ben Hetland

    MACROs are ugly but...

    Ben Hetland, Oct 6, 2005, in forum: C++
    Replies:
    11
    Views:
    555
    Alf P. Steinbach
    Oct 7, 2005
Loading...

Share This Page