Index a #define string

Discussion in 'C++' started by s, Apr 16, 2004.

  1. s

    s Guest

    Can I do this:

    #define MYSTRING "ABC"
    ..
    ..
    ..
    char mychar = MYSTRING[0];
    ..
    ..
    ..



    -Thanks,
    s
    s, Apr 16, 2004
    #1
    1. Advertising

  2. s

    lallous Guest

    "s" <> wrote in message
    news:...
    > Can I do this:
    >
    > #define MYSTRING "ABC"
    > .
    > char mychar = MYSTRING[0];
    >
    > -Thanks,
    > s

    Hello

    Tried it with VC and it works fine.
    Also: char mychar = *MYSTRING works fine.

    --
    Elias
    lallous, Apr 16, 2004
    #2
    1. Advertising

  3. s

    Petec Guest

    s wrote:
    > Can I do this:
    >
    > #define MYSTRING "ABC"
    > .
    > .
    > .
    > char mychar = MYSTRING[0];
    > .
    > .
    > .
    >
    >
    >
    > -Thanks,
    > s


    I would suggest using:
    const char* const MYSTRING = "ABC";

    AFAIK, your #define string thing should work, though.

    - Pete
    Petec, Apr 16, 2004
    #3
  4. s

    David Harmon Guest

    On Fri, 16 Apr 2004 13:51:01 GMT in comp.lang.c++, "Petec" <>
    wrote,
    >I would suggest using:
    >const char* const MYSTRING = "ABC";


    Why the gratuitous pointer?
    const char mystring[] = "ABC";
    David Harmon, Apr 16, 2004
    #4
  5. David Harmon <> spoke thus:

    >>const char* const MYSTRING = "ABC";


    > const char mystring[] = "ABC";


    Are there any situations where the behavior of these two constructs
    differs?

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Apr 16, 2004
    #5
  6. "s" <> wrote in message
    news:...
    > Can I do this:
    >
    > #define MYSTRING "ABC"
    > .
    > .
    > .
    > char mychar = MYSTRING[0];




    Yes, but why do this anyway. Avoid macros completely.

    In this case you can do:

    char mychar="ABC"[0];


    or


    const char * const MYSTRING="ABC";

    char mychar=MYSTRING[0];






    Ioannis Vranos
    Ioannis Vranos, Apr 16, 2004
    #6
  7. s wrote:
    > Can I do this:
    >
    > #define MYSTRING "ABC"
    > .
    > .
    > .
    > char mychar = MYSTRING[0];
    > .
    > .
    > .
    >
    >
    >
    > -Thanks,
    > s


    This is a FAQ, but listed in the C language FAQ.
    Reading the FAQs before posting is always a good
    idea.
    http://www.eskimo.com/~scs/c-faq/q6.11.html


    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    Thomas Matthews, Apr 16, 2004
    #7
  8. s

    John Carson Guest

    "s" <> wrote in message
    news:
    > Can I do this:
    >
    > #define MYSTRING "ABC"
    > .
    > .
    > .
    > char mychar = MYSTRING[0];
    > .


    The preprocessor simply does a text substitution so you end up with:

    char mychar = "ABC"[0];

    This is perfectly valid; it assigns 'A' to mychar. As far as the surrounding
    code is concerned, a string literal is just a pointer.


    --
    John Carson
    1. To reply to email address, remove donald
    2. Don't reply to email address (post here instead)
    John Carson, Apr 16, 2004
    #8
  9. Ioannis Vranos <> spoke thus:

    > Avoid macros completely.


    Not all macros are evil.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Apr 16, 2004
    #9
  10. "Christopher Benson-Manica" <> wrote in message
    news:c5otbd$4jp$...
    > David Harmon <> spoke thus:
    >
    > >>const char* const MYSTRING = "ABC";

    >
    > > const char mystring[] = "ABC";

    >
    > Are there any situations where the behavior of these two constructs
    > differs?



    Behaviour no, but implementation yes. "ABC" is stored in a separate space
    reserved from the implementation, while the pointer MYSTRING and the array
    mystring with all its members are stored in the stack.






    Ioannis Vranos
    Ioannis Vranos, Apr 16, 2004
    #10
  11. s

    Petec Guest

    David Harmon wrote:
    > On Fri, 16 Apr 2004 13:51:01 GMT in comp.lang.c++, "Petec" <>
    > wrote,
    >> I would suggest using:
    >> const char* const MYSTRING = "ABC";

    >
    > Why the gratuitous pointer?
    > const char mystring[] = "ABC";


    It's just my style, and there's not much of a difference.
    Besides, if I want to avoid pointers, I use a std::string.

    - Pete
    Petec, Apr 16, 2004
    #11
  12. "Christopher Benson-Manica" <> wrote in message
    news:c5p07c$5np$...
    >
    > Not all macros are evil.



    We must try to avoid using macros completely (mainly by using templates),
    with very few exceptions that this can't be done (mainly the #ifndef stuff).






    Ioannis Vranos
    Ioannis Vranos, Apr 16, 2004
    #12
  13. s

    David Harmon Guest

    On Fri, 16 Apr 2004 19:07:38 +0300 in comp.lang.c++, "Ioannis Vranos"
    <> wrote,
    >"Christopher Benson-Manica" <> wrote in message
    >news:c5otbd$4jp$...
    >> David Harmon <> spoke thus:
    >>
    >> >>const char* const MYSTRING = "ABC";

    >>
    >> > const char mystring[] = "ABC";

    >>
    >> Are there any situations where the behavior of these two constructs
    >> differs?

    >
    >
    >Behaviour no, but implementation yes. "ABC" is stored in a separate space
    >reserved from the implementation, while the pointer MYSTRING and the array
    >mystring with all its members are stored in the stack.


    Sorry, but no. There is no "stack" at the point in namespace or file
    scope where those declarations are presumably found. It could only be
    on the stack if it were written local to a function, in which case I
    would have written it
    static const char mystring[] = "ABC";

    Unfortunately, "static" means different things at function scope and at
    file scope. Either way it should be merely a name referring to the same
    constant area that the literal does occupy in the various other idioms.
    Putting it on the stack would be very bad, calling for a copy to be made
    from constant area every time you use it.

    The possible extra level of indirection, and possible wasted space for
    a pointer variable that was not called for in the original #define
    example, is a mistake and a red herring and should never have been
    introduced into the discussion. But, if it was at function scope, Pete
    would presumably have declared it "static" also, and still have nothing
    extra on the stack, I hope.
    David Harmon, Apr 16, 2004
    #13
  14. s

    David Harmon Guest

    On Fri, 16 Apr 2004 16:05:00 +0000 (UTC) in comp.lang.c++, Christopher
    Benson-Manica <> wrote,
    >Ioannis Vranos <> spoke thus:
    >
    >> Avoid macros completely.

    >
    >Not all macros are evil.


    Example?
    David Harmon, Apr 16, 2004
    #14
  15. "David Harmon" <> wrote in message
    news:...
    > On Fri, 16 Apr 2004 19:07:38 +0300 in comp.lang.c++, "Ioannis Vranos"
    > <> wrote,
    > >"Christopher Benson-Manica" <> wrote in

    message
    > >news:c5otbd$4jp$...
    > >> David Harmon <> spoke thus:
    > >>
    > >> >>const char* const MYSTRING = "ABC";
    > >>
    > >> > const char mystring[] = "ABC";
    > >>
    > >> Are there any situations where the behavior of these two constructs
    > >> differs?

    > >
    > >
    > >Behaviour no, but implementation yes. "ABC" is stored in a separate space
    > >reserved from the implementation, while the pointer MYSTRING and the

    array
    > >mystring with all its members are stored in the stack.

    >
    > Sorry, but no. There is no "stack" at the point in namespace or file
    > scope where those declarations are presumably found.



    At first, i assumed the definition takes place in a local scope and not in
    the global or a namespace scope.

    But except of that, where do you think global "non-static" variables are
    created?


    > It could only be
    > on the stack if it were written local to a function, in which case I
    > would have written it
    > static const char mystring[] = "ABC";



    There would be no point for this. The time cost for creating this thing is a
    joke. :) (Even the compiler may optimise it entirely out).



    > Unfortunately, "static" means different things at function scope and at
    > file scope.




    Yes, and instead of using static keyword in the global scope it is better to
    use an anonymous namespace.


    > Either way it should be merely a name referring to the same
    > constant area that the literal does occupy in the various other idioms.
    > Putting it on the stack would be very bad, calling for a copy to be made
    > from constant area every time you use it.



    I do not understand what you mean, after all copies will be created inside
    the array in all case scenarios.



    > The possible extra level of indirection, and possible wasted space for
    > a pointer variable that was not called for in the original #define
    > example, is a mistake and a red herring and should never have been
    > introduced into the discussion. But, if it was at function scope, Pete
    > would presumably have declared it "static" also, and still have nothing
    > extra on the stack, I hope.




    You are wrong. static variables inside a function scope are still created in
    the stack.






    Ioannis Vranos
    Ioannis Vranos, Apr 16, 2004
    #15
  16. Ioannis Vranos <> spoke thus:

    > You are wrong. static variables inside a function scope are still created in
    > the stack.


    Assuming the implementation uses a stack.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Apr 16, 2004
    #16
  17. s

    David Harmon Guest

    On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"
    <> wrote,
    >At first, i assumed the definition takes place in a local scope and not in
    >the global or a namespace scope.


    I assumed otherwise, since I have seen some huge number of such #define
    constants in C code, and a somewhat lesser number of const strings in
    C++ code, and the vast majority of them were near the top of the file
    before any functions, if not in headers included near the top of the
    file before any functions.

    >But except of that, where do you think global "non-static" variables are
    >created?


    I don't understand that. All globals have static lifetime, or they
    wouldn't be global. Show me the declaration of what you are talking
    about and I'll tell you where I think it's created.

    >> It could only be
    >> on the stack if it were written local to a function, in which case I
    >> would have written it
    >> static const char mystring[] = "ABC";

    >
    >There would be no point for this. The time cost for creating this thing is a
    >joke. :) (Even the compiler may optimise it entirely out).


    No point for what? There is certainly a point for putting "static" on
    the declaration of that, at function scope, however small the cost of
    omitting it on a string that happens to be very short.

    >> Unfortunately, "static" means different things at function scope and at
    >> file scope.

    >
    >Yes, and instead of using static keyword in the global scope it is better to
    >use an anonymous namespace.


    That's irrelevant. I was not suggesting "static" at global scope, I was
    explaining why I did _not_ use "static" at global scope in the previous
    example. Besides, consts at file scope are "static" in that sense by
    default anyway. For purposes of this thread it matters not whether the
    globals are declared "static" or in a namespace, or neither. It only
    matters regarding the locals.

    >You are wrong. static variables inside a function scope are still created in
    >the stack.


    No, not this time. Static variables wouldn't be static if they were on
    the stack. If they were on the stack, where do you think their values
    would be preserved from one call of the function to the next?

    To illustrate, here is an compilable example:

    const char* const MYSTRING = "ABC";
    const char mystring[] = "ABC";
    int main()
    {
    const char * cptr;
    cptr = mystring; // line 6
    cptr = MYSTRING; // line 7
    static const char mystring[] = "ABC";
    cptr = mystring; // line 9
    static const char* const MYSTRING = "ABC";
    cptr = MYSTRING; // line 11
    }

    I compiled that with MSVC 6.0 with default no optimization options (for
    most straightforward translation) and /Fa for assembly listing output.
    Here is the generated initialized data. You will notice the extra DD
    storage for the two pointers, and that both of the "static" local
    variables with the mangled names are in compile-time initialized
    constant memory, not on the stack.

    CONST SEGMENT
    _MYSTRING DD FLAT:$SG265
    _mystring DB 'ABC', 00H
    _?mystring@?1??main@@9@4QBDB DB 'ABC', 00H
    _?MYSTRING@?1??main@@9@4QBDB DD FLAT:$SG275
    CONST ENDS
    _DATA SEGMENT
    $SG265 DB 'ABC', 00H
    $SG275 DB 'ABC', 00H
    _DATA ENDS

    Now here is the MSVC generated code from the body of main(). Please
    notice that the only variable on the stack is the non-static "cptr".
    At no time does the code copy the characters "ABC\0" to the stack from
    somewhere else. Also, there is the extra instruction required for
    indirection in each of the pointer versions.

    ; Line 6
    mov DWORD PTR _cptr$[ebp], OFFSET FLAT:_mystring
    ; Line 7
    mov eax, DWORD PTR _MYSTRING
    mov DWORD PTR _cptr$[ebp], eax
    ; Line 9
    mov DWORD PTR _cptr$[ebp], OFFSET FLAT:_?mystring@?1??main@@9@4QBDB
    ; Line 11
    mov ecx, DWORD PTR _?MYSTRING@?1??main@@9@4QBDB
    mov DWORD PTR _cptr$[ebp], ecx

    So you see, it is all exactly as I have told you.
    David Harmon, Apr 16, 2004
    #17
  18. "David Harmon" <> wrote in message
    news:...
    > On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"
    > <> wrote,
    > >At first, i assumed the definition takes place in a local scope and not

    in
    > >the global or a namespace scope.

    >
    > I assumed otherwise, since I have seen some huge number of such #define
    > constants in C code, and a somewhat lesser number of const strings in
    > C++ code, and the vast majority of them were near the top of the file
    > before any functions, if not in headers included near the top of the
    > file before any functions.



    The subject is a bit confused. In the case of macros, it doesn't count where
    the macro is defined but where it is used, so since it was substituted
    inside a function (turning MYSTRING[0] to "ABC"[0] before compilation takes
    place), i considered it local. On the other hand he could place my
    suggestions in a header file in the place of the macro definition, but it
    doesn't matter anyway.



    > >> static const char mystring[] = "ABC";

    > >
    > >There would be no point for this. The time cost for creating this thing

    is a
    > >joke. :) (Even the compiler may optimise it entirely out).

    >
    > No point for what? There is certainly a point for putting "static" on
    > the declaration of that, at function scope, however small the cost of
    > omitting it on a string that happens to be very short.



    In this case, i wouldn't use an array myself but a const char * const, but
    never mind. If there isn't a specific advantage for making it static, why
    should one make it of static storage?



    > No, not this time. Static variables wouldn't be static if they were on
    > the stack. If they were on the stack, where do you think their values
    > would be preserved from one call of the function to the next?



    And where they get stored? As far as i know it is implementation-dependent
    but i think the usual is stack.



    >
    > To illustrate, here is an compilable example:
    >
    > const char* const MYSTRING = "ABC";
    > const char mystring[] = "ABC";
    > int main()
    > {
    > const char * cptr;
    > cptr = mystring; // line 6
    > cptr = MYSTRING; // line 7
    > static const char mystring[] = "ABC";
    > cptr = mystring; // line 9
    > static const char* const MYSTRING = "ABC";
    > cptr = MYSTRING; // line 11
    > }
    >
    > I compiled that with MSVC 6.0 with default no optimization options (for
    > most straightforward translation) and /Fa for assembly listing output.
    > Here is the generated initialized data. You will notice the extra DD
    > storage for the two pointers, and that both of the "static" local
    > variables with the mangled names are in compile-time initialized
    > constant memory, not on the stack.
    >
    > CONST SEGMENT
    > _MYSTRING DD FLAT:$SG265
    > _mystring DB 'ABC', 00H
    > _?mystring@?1??main@@9@4QBDB DB 'ABC', 00H
    > _?MYSTRING@?1??main@@9@4QBDB DD FLAT:$SG275
    > CONST ENDS
    > _DATA SEGMENT
    > $SG265 DB 'ABC', 00H
    > $SG275 DB 'ABC', 00H
    > _DATA ENDS



    I see a DD and a DB. But i do not know much of assembly, only very basic
    theoretic, that we fetch data from memory to registers and vice versa,
    e.t.c..

    So you mean that it is in a memory area reserved by the implementation. I
    can agree with that. The static storage space is implementation defined but
    i thought that the usual is stack (at the beginning of it).


    >
    > Now here is the MSVC generated code from the body of main(). Please
    > notice that the only variable on the stack is the non-static "cptr".
    > At no time does the code copy the characters "ABC\0" to the stack from
    > somewhere else.



    You mean that the compiler optimises it out. I can agree with that, but
    there is no guarantee that it will happen with all compilers, even with
    different versions of the same compiler. The overall implementation details
    we are discussing here are implementation-dependent. What i said is that if
    we define a built in array like this as auto, there is no real performance
    gain in most platforms. I think we should define a built in array to have
    static storage only when we see actual benefit from it. In the
    squeeze-every-cycle attitute (that i also had few years ago), you can gain 1
    cycle or two after subsequent function calls with that char array, but in my
    1,000,000 Hz CPU (and i bet you have a faster one) it will not be noticed,
    especially when the system idle process of windows takes 95% of the CPU time
    in the usual workload.

    I consider the use of static only for some object whose creation/destruction
    introduces significant time cost. Now if someone likes to optimise the
    run-time of creation/destruction of some chars, it is fine with me. :)






    Ioannis Vranos
    Ioannis Vranos, Apr 16, 2004
    #18
  19. Christopher Benson-Manica wrote:
    > ...
    >>>const char* const MYSTRING = "ABC";

    >
    >> const char mystring[] = "ABC";

    >
    > Are there any situations where the behavior of these two constructs
    > differs?


    Technically, yes. Remember that, firstly, string literal is an object
    with static storage duration in C++. It has no name but it has its own
    address in storage. And secondly, the implementation is allowed to merge
    identical literals. The consequence of this is that in the following code

    const char* const MYSTRING1 = "ABC";
    const char* const MYSTRING2 = "ABC";

    it is quite possible that both pointers will hold the same value
    (depends on implementation).

    However, if you do it this way

    const char MYSTRING1[] = "ABC";
    const char MYSTRING2[] = "ABC";

    you can be sure that 'MYSTRING1' and 'MYSTRING2' are two different
    objects and values of '&MYSTRING1' and '&MYSTRING2' are guaranteed to be
    different.

    In most cases this behavior makes no difference in the actual program.
    But in some cases it could.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Apr 16, 2004
    #19
  20. s

    Jack Klein Guest

    On Fri, 16 Apr 2004 23:46:01 +0300, "Ioannis Vranos"
    <> wrote in comp.lang.c++:

    > "David Harmon" <> wrote in message
    > news:...


    [snip]

    > In this case, i wouldn't use an array myself but a const char * const, but
    > never mind. If there isn't a specific advantage for making it static, why
    > should one make it of static storage?
    >
    >
    >
    > > No, not this time. Static variables wouldn't be static if they were on
    > > the stack. If they were on the stack, where do you think their values
    > > would be preserved from one call of the function to the next?

    >
    >
    > And where they get stored? As far as i know it is implementation-dependent
    > but i think the usual is stack.


    Since you have no idea at all how hardware stacks are used in typical
    processors under typical C++ implementations, perhaps you shouldn't
    try to answer questions here by discussing them incorrectly.

    --
    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, Apr 17, 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. karthikeyavenkat
    Replies:
    2
    Views:
    555
    Bryce
    Mar 17, 2005
  2. theotyflos
    Replies:
    3
    Views:
    444
    Thomas Matthews
    Feb 19, 2004
  3. robin liu
    Replies:
    3
    Views:
    804
    Robin Liu
    Apr 21, 2006
  4. Brian Takita

    #define _ and #define __

    Brian Takita, Jan 23, 2006, in forum: Ruby
    Replies:
    0
    Views:
    436
    Brian Takita
    Jan 23, 2006
  5. Tomasz Chmielewski

    sorting index-15, index-9, index-110 "the human way"?

    Tomasz Chmielewski, Mar 4, 2008, in forum: Perl Misc
    Replies:
    4
    Views:
    256
    Tomasz Chmielewski
    Mar 4, 2008
Loading...

Share This Page