#define macro to enclose an older macro with strings

Discussion in 'C++' started by Dead RAM, Jul 13, 2004.

  1. Dead RAM

    Dead RAM Guest

    Hey people, i'll try to keep this short ;)

    Here is what I want to type (or at least close too)...

    #define VER_BUILD 1
    #define STR_VER_BUILD "VER_BUILD"

    But what happends is the preprocessor see the quots in STR_VER_BUILD and
    replaces that text with "VER_BUILD"...
    I need it to see the VER_BUILD and replace it with 1, and only after doing
    that replacement enclose the 1 in quots...
    I tried using a number sign without any luck (number sign in a macro that
    takes params encloses the next param in quots).

    #define VER_BUILD 1
    #define THING_TO_STR(thing) # thing
    #define STR_VER_BUILD THING_TO_STR(VER_BUILD)

    Both these tries gave me the result of STR_VER_BUILD being replaced with
    "VER_BUILD"... Instead of what I wanted... VER_BUILD being replaced with 1
    and STR_VER_BUILD being replaced with "1"

    Just so there isn't any confusion... any other place were i used VER_BUILD
    alone, the preprocessor replaced that with 1.
     
    Dead RAM, Jul 13, 2004
    #1
    1. Advertisements

  2. This is a good example of the weirdness that is the C pre-processor. This
    minor variation works

    #define VER_BUILD 1
    #define _THING_TO_STR(thing) # thing
    #define THING_TO_STR(thing) _THING_TO_STR(thing)
    #define STR_VER_BUILD THING_TO_STR(VER_BUILD)

    Don't ask me to explain why because I don't know. It just a trick worth
    knowing.

    john
     
    John Harrison, Jul 13, 2004
    #2
    1. Advertisements

  3. Before some else points it out, identifiers with a leading underscore
    followed by uppercase letter are _NOT_ALLOWED_. Replace _THING_TO_STR with
    something more suitable.

    john
     
    John Harrison, Jul 13, 2004
    #3
  4. Dead RAM

    Guest Guest

    #include <stdio.h>
    #include <stdlib.h>
    #define STR_VER_BUILD "1"
    #define VER_BUILD atoi(STR_VER_BUILD)
    int main(void) {
    printf("%d = \"%s\"\n", VER_BUILD, STR_VER_BUILD);
    return 0;
    }
     
    Guest, Jul 13, 2004
    #4
  5. All identifiers and yes it is Standard. Names starting with an underscore
    followed by an uppercase letter are reserved for the compiler to aid in
    implementing its own macros and templates without interfering with user
    written source code.
     
    Karl Heinz Buchegger, Jul 13, 2004
    #5
  6. Dead RAM

    hack_tick Guest

    hi there
    [..]
    is it just the case with Macros or with All the identifiers ? is it Standard
    ?
     
    hack_tick, Jul 13, 2004
    #6
  7. Dead RAM

    hack_tick Guest

    BTW its working with VC6 for macros and identifiers(i tried with variable's
    name only)
     
    hack_tick, Jul 13, 2004
    #7
  8. Sure it works. This rule is more on the level of an (enforced) agreement.
    There is nothing wrong with those names per se. But the compiler needs some names
    (for macros, templates, ...) on it's own (eg. open the iostream header
    file, if it exists on your implementation and see for yourself). That's
    why the standard reserves such names for exclusive use of compiler writers only.
    Just avoid such names and your macros will not interfere with something you
    get unexpected by including some system header files.
     
    Karl Heinz Buchegger, Jul 13, 2004
    #8
  9. Dead RAM

    Dead RAM Guest

    I don't know how... or why... but ummm... 0.o thanks...

    As a side note... I hate the guy who built the pre-processor... but love the
    brain that caused this hack to show up ;)
     
    Dead RAM, Jul 13, 2004
    #9
  10. Dead RAM

    JKop Guest

    Dead RAM posted:


    This in some perverse way actually pleases me.


    unsigned char const ver_build = 1;

    const char* const str_ver_build = "1";


    -JKop
     
    JKop, Jul 13, 2004
    #10
  11. Dead RAM

    Phlip Guest

    unsigned char const ver_build = 2;
    const char* const str_ver_build = "1";

    Ooops.

    The OP is trying to fold duplication, so changes in only one place propagate
    correctly.
     
    Phlip, Jul 13, 2004
    #11
  12. Dead RAM

    JKop Guest

    Phlip posted:


    I was going to let him you his *own* brain power for the
    rest.
     
    JKop, Jul 13, 2004
    #12
  13. Dead RAM

    Phlip Guest

    I have ... "special" reasons to always avoid relying on brain power.
     
    Phlip, Jul 13, 2004
    #13
  14. Dead RAM

    Ali Cehreli Guest

    Two other reserved names:

    - Identifiers with two leading underscores

    - Identifiers with a leading underscore followed by a lower case
    letter to be used in the global namespace. (I don't remember the exact
    wording of this one, but the reference to the global namespace makes
    it confusing even if I did.)

    All these rules about underscore are good enough reasons to avoid any
    name that has a leading underscore.

    Ali
     
    Ali Cehreli, Jul 13, 2004
    #14
  15. Dead RAM

    AVR Guest

    I'm working on a tool which has several thousand lines of code, and
    around 20 developers working concurrently. The convention we follow (and
    not a novel one, according to our coding standards) is that all private
    variables are to be named with leading underscores, followed by lowercase.
    Though I'm a relative newcomer, I was wondering if such a scheme would
    be adopted in the first place if the points that you made above were
    even considered. Kindly clarify.


    thanks,
    AVR
     
    AVR, Jul 13, 2004
    #15
  16. That scheme is fine, and it's one I use myself (I'm assuming my private
    variable you mean class member variable). What isn't allowed though is to
    use a name with a leading underscore in the global namespace, i.e. outside
    of a class or other namespace.

    john
     
    John Harrison, Jul 13, 2004
    #16
  17. Dead RAM

    Ali Cehreli Guest

    Running the following query at groups.google.com finds some past
    threads on this subject:

    underscore "in the global namespace"

    Quoting from one of those messages, the standard says:

    "each name that begins with an underscore is reserved to the
    implementation for use as a name in the global namespace"

    So it's actually OK to use them for member names.

    I agree with Francis Glassborow's comments in the same thread though:

    "When given a choice between two things that are in almost all
    respects identical but one of which has a possible (if only
    remote) point of failure I universally opt for the other. I know
    that it is unlikely that I will want a global variable visible in
    the scope of a class, but why spend time worrying about it? Using
    a trailing underscore works everywhere and has no lurking nasties,
    leading underscores can result in rare surprises."

    "Actually their very rareness makes them deeply poisonous because
    you won't even be looking for trouble when it strikes (silently)."

    Ali
     
    Ali Cehreli, Jul 13, 2004
    #17
  18. Dead RAM

    Jack Klein Guest

    That's the C version. ISO C++ actually reserves identifiers with two
    successive underscores _anywhere_ within, not just at the beginning.
     
    Jack Klein, Jul 14, 2004
    #18
  19. I'm working on a tool which has several thousand lines of code, and
    I've just read that again. You need 20 programmers for several thousand
    lines of code! Do you all work one day a week or something? Or does
    management keep you so busy with admin that you don't have any time for
    programming?

    Just curious.

    Of course one of the problems of having so many programmers is that you can
    spend all your time ensuring good communication between each other so that
    you don't have any time for coding, which just encourages management to hire
    even more programmers, which just makes the problem worse. See The Mythical
    Man Month by Frederick P Brooks.

    john
     
    John Harrison, Jul 14, 2004
    #19
  20. Dead RAM

    AVR Guest

    Sorry for posting twice. I didn't realize.
    I wasn't concentrating on specifics earlier. I just checked and:

    [[email protected] src]$ find .|grep .cpp$ | sed -e "s/^\ */cat\ /" | bash \
    | wc -l
    72372
    [[email protected] src]$ find .|grep .h$ | sed -e "s/^\ */cat\ /" | bash \
    | wc -l
    48517

    I should have said hundreds of thousands, I guess ;-). And probably
    there aren't 20 employees. Maybe 15. And some are interns like me.
    I agree. This is more so if you don't have regular team meetings etc.
    We do, fortunately.
     
    AVR, Jul 14, 2004
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.