std::string and char[] comparisons

Discussion in 'C++' started by webretard@live.com, Jul 7, 2010.

  1. Guest

    I never used C much and have grown accustomed to C++ std::string. This
    is a weakness because I don't understand why comparisons ( == ) are
    unreliable when dealing only with char[] types. It seems std::string
    is always comparable and that std::string and char[] are always
    comparable, but char[] to char[] comparison works sometimes, but not
    others depending on the content of the char[]. Here is a small snippet
    I wrote to demonstrate:

    int main()
    {

    std::string one = "1qaz2wsx";
    std::string two = "1qaz2wsx";

    // Always matches
    if ( one == two )
    {
    std::cout << "std::string Match" << std::endl;
    std::cout << one << std::endl;
    std::cout << two << std::endl;
    }
    else
    {
    std::cout << "std::string No Match" << std::endl;
    std::cout << one << std::endl;
    std::cout << two << std::endl;
    }

    // ------------------------------------------------------

    char three[9] = "1qaz2wsx";
    char four[9] = "1qaz2wsx";

    // Matches sometimes, not others
    if ( three == four )
    {
    std::cout << "char Match" << std::endl;
    std::cout << three << std::endl;
    std::cout << four << std::endl;
    }
    else
    {
    std::cout << "char No Match" << std::endl;
    std::cout << three << std::endl;
    std::cout << four << std::endl;
    }

    // ------------------------------------------------------

    // Always matches
    if ( one == three )
    {
    std::cout << "std::string and char Match" << std::endl;
    std::cout << three << std::endl;
    std::cout << four << std::endl;
    }
    else
    {
    std::cout << "std::string and char No Match" << std::endl;
    std::cout << three << std::endl;
    std::cout << four << std::endl;
    }

    return 0;
    }

    My goal is to compare char[] just as reliably as I can compare
    std::string objects.

    Terry
    , Jul 7, 2010
    #1
    1. Advertising

  2. , on 07/07/2010 08:09:59, wrote:

    > I never used C much and have grown accustomed to C++ std::string. This
    > is a weakness because I don't understand why comparisons ( == ) are
    > unreliable when dealing only with char[] types. It seems std::string
    > is always comparable and that std::string and char[] are always
    > comparable, but char[] to char[] comparison works sometimes, but not
    > others depending on the content of the char[]. Here is a small snippet
    > I wrote to demonstrate:
    >
    > int main()
    > {
    >
    > std::string one = "1qaz2wsx";
    > std::string two = "1qaz2wsx";
    >
    > // Always matches
    > if ( one == two )
    > {
    > std::cout<< "std::string Match"<< std::endl;
    > std::cout<< one<< std::endl;
    > std::cout<< two<< std::endl;
    > }
    > else
    > {
    > std::cout<< "std::string No Match"<< std::endl;
    > std::cout<< one<< std::endl;
    > std::cout<< two<< std::endl;
    > }
    >
    > // ------------------------------------------------------
    >
    > char three[9] = "1qaz2wsx";
    > char four[9] = "1qaz2wsx";
    >
    > // Matches sometimes, not others
    > if ( three == four )
    > {
    > std::cout<< "char Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    > else
    > {
    > std::cout<< "char No Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    >
    > // ------------------------------------------------------
    >
    > // Always matches
    > if ( one == three )
    > {
    > std::cout<< "std::string and char Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    > else
    > {
    > std::cout<< "std::string and char No Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    >
    > return 0;
    > }
    >
    > My goal is to compare char[] just as reliably as I can compare
    > std::string objects.


    You can't. When you compare char[], you're comparing char*, in other
    words, you're comparing addresses and not the data they point to.

    Read the manual about C strings handling and you'll find the functions
    needed to compare them. Converting them to std::string and comparing
    them is just fine too.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
    Francesco S. Carta, Jul 7, 2010
    #2
    1. Advertising

  3. On 7/7/2010 11:09 AM, wrote:
    > I never used C much and have grown accustomed to C++ std::string. This
    > is a weakness because I don't understand why comparisons ( == ) are
    > unreliable when dealing only with char[] types. It seems std::string
    > is always comparable and that std::string and char[] are always
    > comparable, but char[] to char[] comparison works sometimes, but not
    > others depending on the content of the char[]. Here is a small snippet
    > I wrote to demonstrate:
    >
    > int main()
    > {
    >
    > std::string one = "1qaz2wsx";
    > std::string two = "1qaz2wsx";
    >
    > // Always matches
    > if ( one == two )
    > {
    > std::cout<< "std::string Match"<< std::endl;
    > std::cout<< one<< std::endl;
    > std::cout<< two<< std::endl;
    > }
    > else
    > {
    > std::cout<< "std::string No Match"<< std::endl;
    > std::cout<< one<< std::endl;
    > std::cout<< two<< std::endl;
    > }
    >
    > // ------------------------------------------------------
    >
    > char three[9] = "1qaz2wsx";
    > char four[9] = "1qaz2wsx";
    >
    > // Matches sometimes, not others


    If the compiler optimizes your strings to share the memory location
    (since it can see that you never change the contents of the arrays), you
    can get equality. Otherwise, they will always be different.

    > if ( three == four )
    > {
    > std::cout<< "char Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    > else
    > {
    > std::cout<< "char No Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    >
    > // ------------------------------------------------------
    >
    > // Always matches
    > if ( one == three )
    > {
    > std::cout<< "std::string and char Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    > else
    > {
    > std::cout<< "std::string and char No Match"<< std::endl;
    > std::cout<< three<< std::endl;
    > std::cout<< four<< std::endl;
    > }
    >
    > return 0;
    > }
    >
    > My goal is to compare char[] just as reliably as I can compare
    > std::string objects.


    You can't. Comparing pointers just doesn't work in C++. The array name
    used in an expression decays into a pointer to the first element of the
    array. Two pointers compare equal when they point to the same object.
    In general two arrays occupy different memory (and if your compiler
    somehow optimizes the memory allocation to make the arrays share the
    memory, it can actually be a BAD THING(tm)).

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Jul 7, 2010
    #3
  4. James Kanze Guest

    On Jul 7, 4:17 pm, Victor Bazarov <> wrote:
    > On 7/7/2010 11:09 AM, wrote:


    > > My goal is to compare char[] just as reliably as I can
    > > compare std::string objects.


    > You can't.


    Without using a function.

    > Comparing pointers just doesn't work in C++.


    Comparing pointers works very well: == returns true if the
    pointers point to the same memory, and false if they don't. The
    problem here is that the poster doesn't want to compare
    pointers.

    > The array name used in an expression decays into a pointer to
    > the first element of the array.


    The initial problem is that == isn't defined on arrays, and it
    is on pointers. So the automatic conversion kicks in.

    > Two pointers compare equal when they point to the same object.
    > In general two arrays occupy different memory (and if your
    > compiler somehow optimizes the memory allocation to make the
    > arrays share the memory, it can actually be a BAD THING(tm)).


    In his actual code, the language guarantees that the two arrays
    have different addresses. (Either his comment "matches
    sometimes, not others" is mistaken, or his compiler has an
    error.) The compiler *is* allowed to place different string
    literals at the same address, however; if you do:

    char const* f1 = "abc";
    char const* f2 = "abc";

    , it's unspecified whether f1 == f2. (I'm not sure, but I think
    even the following is allowed:

    char const* f1 = "0abc";
    char const* f2 = "abc";
    if (f1 + 1 == f2) ...

    ..)

    --
    James Kanze
    James Kanze, Jul 7, 2010
    #4
  5. James Kanze Guest

    On Jul 7, 4:20 pm, Stuart Golodetz
    <> wrote:
    > Stuart Golodetz wrote:
    > > wrote:


    > >> int main()
    > >> {

    [...]
    > >> char three[9] = "1qaz2wsx";
    > >> char four[9] = "1qaz2wsx";

    >
    > >> // Matches sometimes, not others
    > >> if ( three == four )
    > >> {
    > >> std::cout << "char Match" << std::endl;
    > >> std::cout << three << std::endl;
    > >> std::cout << four << std::endl;
    > >> }
    > >> else
    > >> {
    > >> std::cout << "char No Match" << std::endl;
    > >> std::cout << three << std::endl;
    > >> std::cout << four << std::endl;
    > >> }


    [...]
    > > three and four decay to char* when you do the comparison
    > > three == four, at which point you are comparing the pointers
    > > not the C-style strings to which they point. If (instead of
    > > using arrays) you'd written


    > > const char *three = "whatever";
    > > const char *four = "whatever";


    It is *not* the same. Special rules apply to string literals.

    > > then a compiler might (I think) spot an optimization
    > > opportunity and store only one copy of the string literal,
    > > at which point the pointers might then be set to the same
    > > thing and compare equal. But if you're using arrays then
    > > I wouldn't expect this to happen.


    > ...although perhaps I should if the compiler can prove neither
    > array is later changed, judging by Victor's reply.


    No. According to the standard, three and four are distinct
    objects, and must have distinct addresses. A compiler can merge
    them (or do anything else it wants), *if* *and* *only* *if* it
    can prove that this has no effect on the "observable behavior"
    of the program. In this case, it quite clearly does have an
    effect on the observable behavior.

    --
    James Kanze
    James Kanze, Jul 7, 2010
    #5
  6. Terry Guest

    On Jul 7, 11:15 am, "Francesco S. Carta" <> wrote:
    > , on 07/07/2010 08:09:59, wrote:
    >
    >
    >
    > > I never used C much and have grown accustomed to C++ std::string. This
    > > is a weakness because I don't understand why comparisons ( == ) are
    > > unreliable when dealing only with char[] types. It seems std::string
    > > is always comparable and that std::string and char[] are always
    > > comparable, but char[] to char[] comparison works sometimes, but not
    > > others depending on the content of the char[]. Here is a small snippet
    > > I wrote to demonstrate:

    >
    > > int main()
    > > {

    >
    > >    std::string one = "1qaz2wsx";
    > >    std::string two = "1qaz2wsx";

    >
    > >          // Always matches
    > >    if ( one == two )
    > >    {
    > >            std::cout<<  "std::string Match"<<  std::endl;
    > >            std::cout<<  one<<  std::endl;
    > >            std::cout<<  two<<  std::endl;
    > >    }
    > >    else
    > >    {
    > >            std::cout<<  "std::string No Match"<<  std::endl;
    > >            std::cout<<  one<<  std::endl;
    > >            std::cout<<  two<<  std::endl;
    > >    }

    >
    > > // ------------------------------------------------------

    >
    > >    char three[9] = "1qaz2wsx";
    > >    char four[9] =  "1qaz2wsx";

    >
    > >          // Matches sometimes, not others
    > >    if ( three == four )
    > >    {
    > >            std::cout<<  "char Match"<<  std::endl;
    > >            std::cout<<  three<<  std::endl;
    > >            std::cout<<  four<<  std::endl;
    > >    }
    > >    else
    > >    {
    > >            std::cout<<  "char No Match"<<  std::endl;
    > >            std::cout<<  three<<  std::endl;
    > >            std::cout<<  four<<  std::endl;
    > >    }

    >
    > > // ------------------------------------------------------

    >
    > >          // Always matches
    > >    if ( one == three )
    > >    {
    > >            std::cout<<  "std::string and char Match"<<  std::endl;
    > >            std::cout<<  three<<  std::endl;
    > >            std::cout<<  four<<  std::endl;
    > >    }
    > >    else
    > >    {
    > >            std::cout<<  "std::string and char No Match"<<  std::endl;
    > >            std::cout<<  three<<  std::endl;
    > >            std::cout<<  four<<  std::endl;
    > >    }

    >
    > >    return 0;
    > > }

    >
    > > My goal is to compare char[] just as reliably as I can compare
    > > std::string objects.

    >
    > You can't. When you compare char[], you're comparing char*, in other
    > words, you're comparing addresses and not the data they point to.
    >
    > Read the manual about C strings handling and you'll find the functions
    > needed to compare them. Converting them to std::string and comparing
    > them is just fine too.
    >
    > --
    >   FSC -http://userscripts.org/scripts/show/59948
    >  http://fscode.altervista.org-http://sardinias.com


    Thank you all. I understand now and have found that converting to
    std::string works well for me:

    char one[9] = "1qaz2wsx";
    char two[9] = "1qaz2wsx";

    std::string my_one( one, 8 );

    // Always matches
    if ( my_one == two )
    ...

    Thanks to all. This list is a helpful place.

    Terry
    Terry, Jul 7, 2010
    #6
  7. Terry <>, on 07/07/2010 09:40:22, wrote:

    > On Jul 7, 11:15 am, "Francesco S. Carta"<> wrote:
    >> , on 07/07/2010 08:09:59, wrote:
    >>
    >>
    >>
    >>> I never used C much and have grown accustomed to C++ std::string. This
    >>> is a weakness because I don't understand why comparisons ( == ) are
    >>> unreliable when dealing only with char[] types. It seems std::string
    >>> is always comparable and that std::string and char[] are always
    >>> comparable, but char[] to char[] comparison works sometimes, but not
    >>> others depending on the content of the char[]. Here is a small snippet
    >>> I wrote to demonstrate:

    >>
    >>> int main()
    >>> {

    >>
    >>> std::string one = "1qaz2wsx";
    >>> std::string two = "1qaz2wsx";

    >>
    >>> // Always matches
    >>> if ( one == two )
    >>> {
    >>> std::cout<< "std::string Match"<< std::endl;
    >>> std::cout<< one<< std::endl;
    >>> std::cout<< two<< std::endl;
    >>> }
    >>> else
    >>> {
    >>> std::cout<< "std::string No Match"<< std::endl;
    >>> std::cout<< one<< std::endl;
    >>> std::cout<< two<< std::endl;
    >>> }

    >>
    >>> // ------------------------------------------------------

    >>
    >>> char three[9] = "1qaz2wsx";
    >>> char four[9] = "1qaz2wsx";

    >>
    >>> // Matches sometimes, not others
    >>> if ( three == four )
    >>> {
    >>> std::cout<< "char Match"<< std::endl;
    >>> std::cout<< three<< std::endl;
    >>> std::cout<< four<< std::endl;
    >>> }
    >>> else
    >>> {
    >>> std::cout<< "char No Match"<< std::endl;
    >>> std::cout<< three<< std::endl;
    >>> std::cout<< four<< std::endl;
    >>> }

    >>
    >>> // ------------------------------------------------------

    >>
    >>> // Always matches
    >>> if ( one == three )
    >>> {
    >>> std::cout<< "std::string and char Match"<< std::endl;
    >>> std::cout<< three<< std::endl;
    >>> std::cout<< four<< std::endl;
    >>> }
    >>> else
    >>> {
    >>> std::cout<< "std::string and char No Match"<< std::endl;
    >>> std::cout<< three<< std::endl;
    >>> std::cout<< four<< std::endl;
    >>> }

    >>
    >>> return 0;
    >>> }

    >>
    >>> My goal is to compare char[] just as reliably as I can compare
    >>> std::string objects.

    >>
    >> You can't. When you compare char[], you're comparing char*, in other
    >> words, you're comparing addresses and not the data they point to.
    >>
    >> Read the manual about C strings handling and you'll find the functions
    >> needed to compare them. Converting them to std::string and comparing
    >> them is just fine too.
    >>
    >> --
    >> FSC -http://userscripts.org/scripts/show/59948
    >> http://fscode.altervista.org-http://sardinias.com

    >
    > Thank you all. I understand now and have found that converting to
    > std::string works well for me:
    >
    > char one[9] = "1qaz2wsx";
    > char two[9] = "1qaz2wsx";
    >
    > std::string my_one( one, 8 );
    >
    > // Always matches
    > if ( my_one == two )
    > ...
    >
    > Thanks to all. This list is a helpful place.


    You're welcome.

    Once you're there, consider completely avoiding to use char arrays and
    limiting the use of the sole const char* to the places you really need
    to - if any.

    One of the things allowed for legacy with C is to assign the address of
    a string literal to a char* like this:

    char* pc = "test";

    That's the reason of stressing "const char*" in passage above.

    You'll get a strong thrust in your understanding of C++ (and its
    different approach wrt to C) by reading the C++ FAQ, you'll not regret
    it, good luck.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
    Francesco S. Carta, Jul 7, 2010
    #7
  8. James Kanze Guest

    On Jul 7, 11:51 pm, Stuart Golodetz
    <> wrote:

    [...]
    > >> ...although perhaps I should if the compiler can prove neither
    > >> array is later changed, judging by Victor's reply.


    > > No. According to the standard, three and four are distinct
    > > objects, and must have distinct addresses. A compiler can merge
    > > them (or do anything else it wants), *if* *and* *only* *if* it
    > > can prove that this has no effect on the "observable behavior"
    > > of the program. In this case, it quite clearly does have an
    > > effect on the observable behavior.


    > Ok, makes sense - the observable effect in this case being that you
    > always expect the comparison in the array case to return false, and the
    > compiler merging them would cause it to return true. I'm puzzled by the
    > OP's "Matches sometimes, not others" comment in that case (and I was
    > when I wrote my original reply, hence the "But if you're using arrays
    > then I wouldn't expect this to happen").


    I am too. For the code he posted, the standard requires the
    strings to compare different. Either some compiler's optimizer
    is a bit too eager (or he was compiling in a non-standard
    compliant mode), or the differences he saw were from a slightly
    different variant of code than what he posted.

    > To clarify what I think is the case now then:


    > * In the string literal case, the compiler *may* (but doesn't have to)
    > optimize and put them in the same place, so the comparison may
    > potentially return either true or false (depending on whether the
    > optimization happens).


    > * In the array case, the comparison is guaranteed to return false,
    > unless your compiler is broken.


    > Is that correct?


    Exactly.

    --
    James Kanze
    James Kanze, Jul 8, 2010
    #8
  9. On 7 juil, 17:09, wrote:
    > I never used C much and have grown accustomed to C++ std::string. This
    > is a weakness because I don't understand why comparisons ( == ) are
    > unreliable when dealing only with char[] types. It seems std::string
    > is always comparable and that std::string and char[] are always
    > comparable, but char[] to char[] comparison works sometimes, but not
    > others depending on the content of the char[]. Here is a small snippet
    > I wrote to demonstrate:


    [snip]

    > My goal is to compare char[] just as reliably as I can compare
    > std::string objects.


    And what would be the comparison ? Should they have the same memory
    representation (equal size && memcmp() == 0) or the same string
    representation (strcmp()==0).

    In the first case, it is useless for string comparison because:
    char a[10]="012345";
    char b[] ="012345";
    would lead to a!=b (they don't have the same size)

    In the second case, it would have no meaning for other types.

    As a conclusion, for strings, you don't need the char[]/char*
    distinction.

    If you need some security check you can use a custom structure:
    #include <cstdlib>
    #include <iostream>
    #include <string.h>


    template<int N>
    struct StrArrayType
    {
    const char* data;
    enum{ size = N } ;

    StrArrayType( char const * v):data(v){}
    };

    template<int N>
    StrArrayType<N> Str( char const (&data)[N] )
    {
    return data;
    }

    template<int N>
    bool operator==( StrArrayType<N> const & lhs , char const *rhs )
    {
    return ::strncmp(lhs.data,rhs,N) == 0;
    }
    template<int N, int M>
    bool operator==( StrArrayType<N> const & lhs , StrArrayType<M> const &
    rhs )
    {
    return ::strncmp(lhs.data,rhs.data,N>M?M:N) == 0;
    }

    int main()
    {
    char a[]="Test1";
    char b[10]="Test1";

    std::cout<<a<<(a==b?"==":"!=")<<b<<std::endl;
    std::cout<<a<<(Str(a)==b?"==":"!=")<<b<<std::endl;
    std::cout<<a<<(Str(a)==Str(b)?"==":"!=")<<b<<std::endl;
    }

    Output:
    Test1!=Test1
    Test1==Test1
    Test1==Test1

    But there is always the risk to forgot Str() somewhere; so you should
    perhaps stick with strings.

    --
    Michael
    Michael Doubez, Jul 8, 2010
    #9
  10. On 08/07/2010 0.51, Stuart Golodetz wrote:
    [...]
    > To clarify what I think is the case now then:
    >
    > * In the string literal case, the compiler *may* (but doesn't have to)
    > optimize and put them in the same place, so the comparison may
    > potentially return either true or false (depending on whether the
    > optimization happens).
    >
    > * In the array case, the comparison is guaranteed to return false,
    > unless your compiler is broken.


    Just to clarify: it's not a "string literal vs. array" issue but
    "pointer to some char vs. copy into a new array" issue.

    Both

    a) char const * p = "something" ;
    b) char const arr[] = "something" ;

    involve string literals. A string literal is a purely
    compile-time entity (a token) but also has an associated array
    with static duration (for the literary eternity of this post
    let's call it the "associated array"; some confusion arises
    exactly when *this* array is called the "string literal").

    So both have a string literal and both "have" an array; the
    difference is that in (a) you point into that array directly
    (because the language says so), while in (b) you "make a copy".

    It is *unspecified* whether two string-literals result in
    distinct arrays so two pointers formed "the (a) way" may, in
    general, compare equal.

    As an aside, I always use form (b) but it would be quite long to
    explain why... After all, there's a reason why the specification
    of __func__ is given in terms of (b), too :)

    (I hope the post just clarified a possible source of confusion.
    Summarizing language rules this way is often tricky or outright
    impossible; and if one really wants to, there's a lot of
    nitpicking that can be done, say on the difference between
    "string literal" and "string-literal", between expression and
    token or on the fact that string literals can be concatenated in
    various ways, or even by going to the C standard and finding
    phrases along the lines of "attempt to modify a string-literal"
    or "an implementation may make string literals modifiable" (from
    memory), which would "prove" some of my distinctions wrong. But
    neither the C standard or the C++ one are written on such
    grounds of precision and coherence as to withstand this sort of
    exercises; basically one has to understand the intent or just
    read Russel :))

    --
    Gennaro Prota | name.surname yahoo.com
    Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
    Do you need expertise in C++? I'm available.
    Gennaro Prota, Jul 8, 2010
    #10
  11. On 08/07/2010 20.02, Stuart Golodetz wrote:
    > Gennaro Prota wrote:
    >> On 08/07/2010 0.51, Stuart Golodetz wrote:
    >> [...]
    >>> To clarify what I think is the case now then:
    >>>
    >>> * In the string literal case, the compiler *may* (but doesn't have to)
    >>> optimize and put them in the same place, so the comparison may
    >>> potentially return either true or false (depending on whether the
    >>> optimization happens).
    >>>
    >>> * In the array case, the comparison is guaranteed to return false,
    >>> unless your compiler is broken.

    >>
    >> Just to clarify: it's not a "string literal vs. array" issue but
    >> "pointer to some char vs. copy into a new array" issue.
    >>
    >> Both
    >>
    >> a) char const * p = "something" ;
    >> b) char const arr[] = "something" ;
    >>
    >> involve string literals. A string literal is a purely
    >> compile-time entity (a token) but also has an associated array
    >> with static duration (for the literary eternity of this post
    >> let's call it the "associated array"; some confusion arises
    >> exactly when *this* array is called the "string literal").
    >>
    >> So both have a string literal and both "have" an array; the
    >> difference is that in (a) you point into that array directly
    >> (because the language says so), while in (b) you "make a copy".
    >>
    >> It is *unspecified* whether two string-literals result in
    >> distinct arrays so two pointers formed "the (a) way" may, in
    >> general, compare equal.
    >>
    >> As an aside, I always use form (b) but it would be quite long to
    >> explain why... After all, there's a reason why the specification
    >> of __func__ is given in terms of (b), too :)
    >>
    >> (I hope the post just clarified a possible source of confusion.
    >> Summarizing language rules this way is often tricky or outright
    >> impossible; and if one really wants to, there's a lot of
    >> nitpicking that can be done, say on the difference between
    >> "string literal" and "string-literal", between expression and
    >> token or on the fact that string literals can be concatenated in
    >> various ways, or even by going to the C standard and finding
    >> phrases along the lines of "attempt to modify a string-literal"
    >> or "an implementation may make string literals modifiable" (from
    >> memory), which would "prove" some of my distinctions wrong. But
    >> neither the C standard or the C++ one are written on such
    >> grounds of precision and coherence as to withstand this sort of
    >> exercises; basically one has to understand the intent or just
    >> read Russel :))

    >
    > Thanks Gennaro :) That definitely helps clarify matters.
    >
    > Cheers,
    > Stu
    >
    > p.s. I'm going to regret asking this, but what *is* the difference
    > between "string literal" and "string-literal"? :)


    _Usually_ (but it's really just an observation on my part and
    probably you could find exceptions or border-line cases) the C++
    standard uses the hyphenated spelling, "string-literal", in
    grammar productions and the other one elsewhere.

    <NOTE>
    I haven't respected this distinction, and my post above
    interchanges the two forms more or less at random, including in
    the "from-memory" hypothetical quotes from the C standard; sorry
    for that; I should have done a better job at copy-editing.
    </NOTE>

    But I was just trying to prevent a useless "language-lawyering
    subthread": someone might have taken my sentence "a string
    literal is a purely compile-time entity (a token)" and objected
    that actually a string literal is an expression, thus it also
    "has a life" in runtime (because that's when it is "evaluated").

    From there, we would have probably had posts highlighting that
    "string-literals" are tokens while "string literals" are
    expressions, and things like that. Then probably someone would
    have found a sentence in the standard that didn't fit the scheme
    and either use it to confuse the whole discussion (a calamity,
    IMHO; I find it important that people reading the newsgroup
    archives can really find answers, rather than getting lost into
    endless threads) or to file an official defect report. I've seen
    all this, a lot of times, although probably it's more frequent
    on the moderated counterpart.

    --
    Gennaro Prota | name.surname yahoo.com
    Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
    Do you need expertise in C++? I'm available.
    Gennaro Prota, Jul 10, 2010
    #11
  12. James Kanze Guest

    On Jul 10, 2:26 pm, Gennaro Prota <> wrote:
    > On 08/07/2010 20.02, Stuart Golodetz wrote:


    [...]
    > > p.s. I'm going to regret asking this, but what *is* the difference
    > > between "string literal" and "string-literal"? :)


    > _Usually_ (but it's really just an observation on my part and
    > probably you could find exceptions or border-line cases) the
    > C++ standard uses the hyphenated spelling, "string-literal",
    > in grammar productions and the other one elsewhere.


    I think it's pretty general.

    There really is a distinction in this case: given something
    like:

    char c[] = "some text";

    , the string in the code is a string-literal, but there are no
    string literals (which cannot be modified, and can be shared).

    --
    James Kanze
    James Kanze, Jul 12, 2010
    #12
    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. Peter Jansson
    Replies:
    5
    Views:
    6,300
    Ivan Vecerina
    Mar 17, 2005
  2. lovecreatesbeauty
    Replies:
    1
    Views:
    1,043
    Ian Collins
    May 9, 2006
  3. Jim Langston

    std::string = char* + std::string

    Jim Langston, Jun 30, 2005, in forum: C++
    Replies:
    9
    Views:
    373
    Jim Langston
    Jul 2, 2005
  4. Jeffrey Walton
    Replies:
    10
    Views:
    938
    Mathias Gaunard
    Nov 26, 2006
  5. Replies:
    3
    Views:
    8,796
Loading...

Share This Page