#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. Advertising

  2. "Dead RAM" <> wrote in message
    news:1oPIc.911822$...
    > 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"
    >


    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. Advertising

  3. >
    > #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)
    >


    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 wrote:

    > 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.


    #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;
    }
     
    =?UTF-8?B?IkRhcmlvIChkcmlua2luZyBjb++sgGVlIGluIHRo, Jul 13, 2004
    #4
  5. hack_tick wrote:
    >
    > hi there
    > "John Harrison" <> wrote in message
    > news:...
    > [..]
    > > 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.

    >
    > is it just the case with Macros or with All the identifiers ? is it Standard


    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
     
    Karl Heinz Buchegger, Jul 13, 2004
    #5
  6. Dead RAM

    hack_tick Guest

    hi there
    "John Harrison" <> wrote in message
    news:...
    [..]
    > 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.


    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. hack_tick wrote:
    >
    > BTW its working with VC6 for macros and identifiers(i tried with variable's
    > name only)


    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
     
    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:


    > #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"



    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

    JKop wrote:

    > This in some perverse way actually pleases me.
    >
    > unsigned char const ver_build = 1;
    >
    > const char* const str_ver_build = "1";


    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
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Jul 13, 2004
    #11
  12. Dead RAM

    JKop Guest

    Phlip posted:

    > JKop wrote:
    >
    >> This in some perverse way actually pleases me.
    >>
    >> unsigned char const ver_build = 1;
    >>
    >> const char* const str_ver_build = "1";

    >
    > 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.
    >




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

    Phlip Guest

    Phlip, Jul 13, 2004
    #13
  14. Dead RAM

    Ali Cehreli Guest

    On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:


    >> #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)
    >>
    >>

    > 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.


    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

    Ali Cehreli wrote:

    > On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:
    >
    >
    >
    >>>#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)
    >>>
    >>>

    >>
    >>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.

    >
    >
    > 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.


    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. On Wed, 14 Jul 2004 00:28:51 +0530, AVR <>
    wrote:

    > Ali Cehreli wrote:
    >
    >> On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:
    >>
    >>>> #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)
    >>>>
    >>>>
    >>>
    >>> 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.

    >> 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.

    >
    > 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.
    >


    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

    On Tue, 13 Jul 2004 11:58:51 -0700, AVR wrote:

    > Ali Cehreli wrote:
    >
    >> On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:
    >>
    >>
    >>
    >>>>#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)
    >>>>
    >>>>
    >>>>
    >>>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.

    >>
    >>
    >> 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.

    >
    > 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.


    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

    On Tue, 13 Jul 2004 11:52:08 -0700, Ali Cehreli <>
    wrote in comp.lang.c++:

    > On Tue, 13 Jul 2004 04:54:04 -0700, John Harrison wrote:
    >
    >
    > >> #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)
    > >>
    > >>

    > > 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.

    >
    > Two other reserved names:
    >
    > - Identifiers with two leading underscores


    That's the C version. ISO C++ actually reserves identifiers with two
    successive underscores _anywhere_ within, not just at the beginning.

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


    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jul 14, 2004
    #18
  19. > I'm working on a tool which has several thousand lines of code, and
    > around 20 developers working concurrently.


    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

    John Harrison wrote:

    >> I'm working on a tool which has several thousand lines of code, and
    >>around 20 developers working concurrently.

    >
    >
    > I've just read that again. You need 20 programmers for several thousand


    Sorry for posting twice. I didn't realize.

    > 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?


    I wasn't concentrating on specifics earlier. I just checked and:

    [avr@localhost src]$ find .|grep .cpp$ | sed -e "s/^\ */cat\ /" | bash \
    | wc -l
    72372
    [avr@localhost 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.

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


    I agree. This is more so if you don't have regular team meetings etc.
    We do, fortunately.

    > Man Month by Frederick P Brooks.
    >
    > john
    >
    >
     
    AVR, Jul 14, 2004
    #20
    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. Andreas N

    Regexp to enclose text with P-tag

    Andreas N, May 18, 2004, in forum: Perl
    Replies:
    1
    Views:
    534
    J├╝rgen Exner
    May 18, 2004
  2. Cram TeXeD
    Replies:
    0
    Views:
    381
    Cram TeXeD
    Apr 6, 2004
  3. SubZane

    Regexp to enclose text with P-tag

    SubZane, May 18, 2004, in forum: Python
    Replies:
    1
    Views:
    286
    Heiko Wundram
    May 18, 2004
  4. Andreas N

    Regexp to enclose text with P-tag

    Andreas N, May 18, 2004, in forum: Python
    Replies:
    0
    Views:
    291
    Andreas N
    May 18, 2004
  5. puzzlecracker

    enclose a negative number in columns

    puzzlecracker, Dec 19, 2008, in forum: C++
    Replies:
    9
    Views:
    401
    Martin Eisenberg
    Dec 22, 2008
Loading...

Share This Page