strcmp vs. string::compare(const string &)

Discussion in 'C++' started by lchian@yahoo.com, Feb 28, 2006.

  1. Guest

    Hi,

    For two stl strings s1 and s2, I got different results from

    strcmp(s1.c_str(), s2.c_str())
    and
    s1.compare(s2)

    can someone explain what these functions do? It seems that strcmp
    gives the "right" (i.e.wysiwyg) answer while compare() does not.
     
    , Feb 28, 2006
    #1
    1. Advertising

  2. wrote:
    > For two stl strings s1 and s2, I got different results from
    >
    > strcmp(s1.c_str(), s2.c_str())
    > and
    > s1.compare(s2)
    >
    > can someone explain what these functions do? It seems that strcmp
    > gives the "right" (i.e.wysiwyg) answer while compare() does not.


    'compare' takes into consideration _all_ contents, including any number
    of the "terminating" null characters. 'c_str()' effectively truncates
    the contents at the first null character.

    Try comparing the "size"s of s1 and s2.

    V
    --
    Please remove capital As from my address when replying by mail
     
    Victor Bazarov, Feb 28, 2006
    #2
    1. Advertising

  3. Default User Guest

    wrote:

    > Hi,
    >
    > For two stl strings s1 and s2, I got different results from
    >
    > strcmp(s1.c_str(), s2.c_str())
    > and
    > s1.compare(s2)
    >
    > can someone explain what these functions do? It seems that strcmp
    > gives the "right" (i.e.wysiwyg) answer while compare() does not.


    Post a complete program that demonstrates the problem. The one I'll
    show below does NOT exhibit that behavior:

    #include <string.h>
    #include <string>

    int main(void)
    {
    using namespace std; // quick and dirty

    string s1 = "foo";
    string s2 = "bar";

    if (!strcmp(s1.c_str(), s2.c_str()))
    cout << "match\n";
    else
    cout << "no match\n";

    if (!s1.compare(s2))
    cout << "match\n";
    else
    cout << "no match\n";


    string s3 = "foo";
    string s4 = "foo";

    if (!strcmp(s3.c_str(), s4.c_str()))
    cout << "match\n";
    else
    cout << "no match\n";

    if (!s3.compare(s4))
    cout << "match\n";
    else
    cout << "no match\n";

    return 0;
    }


    Results:

    no match
    no match
    match
    match



    Brian
    --
    Please quote enough of the previous message for context. To do so from
    Google, click "show options" and use the Reply shown in the expanded
    header.
     
    Default User, Feb 28, 2006
    #3
  4. Default User wrote:
    > wrote:
    >
    >
    >>Hi,
    >>
    >> For two stl strings s1 and s2, I got different results from
    >>
    >> strcmp(s1.c_str(), s2.c_str())
    >> and
    >> s1.compare(s2)
    >>
    >> can someone explain what these functions do? It seems that strcmp
    >>gives the "right" (i.e.wysiwyg) answer while compare() does not.

    >
    >
    > Post a complete program that demonstrates the problem. The one I'll
    > show below does NOT exhibit that behavior:
    >
    > #include <string.h>
    > #include <string>
    >
    > int main(void)
    > {
    > using namespace std; // quick and dirty
    >
    > string s1 = "foo";
    > string s2 = "bar";
    >
    > if (!strcmp(s1.c_str(), s2.c_str()))
    > cout << "match\n";
    > else
    > cout << "no match\n";
    >
    > if (!s1.compare(s2))
    > cout << "match\n";
    > else
    > cout << "no match\n";
    >
    >
    > string s3 = "foo";
    > string s4 = "foo";


    Add

    s3.append(5, 0); // add 5 zeros at the end

    and see what happens.

    >
    > if (!strcmp(s3.c_str(), s4.c_str()))
    > cout << "match\n";
    > else
    > cout << "no match\n";
    >
    > if (!s3.compare(s4))
    > cout << "match\n";
    > else
    > cout << "no match\n";
    >
    > return 0;
    > }
    >
    >
    > Results:
    >
    > no match
    > no match
    > match
    > match
    >
    >
    >
    > Brian


    V
    --
    Please remove capital As from my address when replying by mail
     
    Victor Bazarov, Feb 28, 2006
    #4
  5. Default User Guest

    Victor Bazarov wrote:

    > Default User wrote:


    [snip code]


    > Add
    >
    > s3.append(5, 0); // add 5 zeros at the end
    >
    > and see what happens.


    I know what would happen. Does the OP? As I said, without seeing the
    code he's running, there's no way to tell. Mine was an example of usage
    that got different results than he reported. He should use that to
    compare with his and see what the differences are.

    It could be he's not using one of the routines correctly. It could be
    that his strings aren't really equal, perhaps for the reason you
    mention. We can't tell.

    The ball's in his court. There's really no point in further discussion
    without a complete program to analyze.
     
    Default User, Mar 1, 2006
    #5
  6. Kai-Uwe Bux Guest

    Victor Bazarov wrote:

    > wrote:
    >> For two stl strings s1 and s2, I got different results from
    >>
    >> strcmp(s1.c_str(), s2.c_str())
    >> and
    >> s1.compare(s2)
    >>
    >> can someone explain what these functions do? It seems that strcmp
    >> gives the "right" (i.e.wysiwyg) answer while compare() does not.

    >
    > 'compare' takes into consideration _all_ contents, including any number
    > of the "terminating" null characters. 'c_str()' effectively truncates
    > the contents at the first null character.


    Nitpick: it's not c_str() truncating the strings, it's strcmp() only reading
    until it finds the first null character.


    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Mar 1, 2006
    #6
  7. Kai-Uwe Bux wrote:
    > Victor Bazarov wrote:
    >
    >
    >> wrote:
    >>
    >>> For two stl strings s1 and s2, I got different results from
    >>>
    >>> strcmp(s1.c_str(), s2.c_str())
    >>> and
    >>> s1.compare(s2)
    >>>
    >>> can someone explain what these functions do? It seems that strcmp
    >>>gives the "right" (i.e.wysiwyg) answer while compare() does not.

    >>
    >>'compare' takes into consideration _all_ contents, including any number
    >>of the "terminating" null characters. 'c_str()' effectively truncates
    >>the contents at the first null character.

    >
    >
    > Nitpick: it's not c_str() truncating the strings, it's strcmp() only reading
    > until it finds the first null character.


    Where is the guarantee that the pointer 'c_str()' returns in _not_ to some
    temporary buffer that only contains characters up to and including the
    first null char? Note that if the 'data()' of the std::string does _not_
    contain a null char, the string _has_ to create a temporary buffer. So,
    it is _most_ likely that the temporary buffer is created. And if it is,
    there is no sense for the 'string' to copy anything there beyond the first
    null character. Hence, the scenario where the 'string' truncates is as
    equally plausible as the one where it doesn't.

    V
    --
    Please remove capital As from my address when replying by mail
     
    Victor Bazarov, Mar 1, 2006
    #7
  8. peter koch Guest

    Victor Bazarov wrote:
    > Kai-Uwe Bux wrote:
    > > Victor Bazarov wrote:
    > >
    > >
    > >> wrote:
    > >>
    > >>> For two stl strings s1 and s2, I got different results from
    > >>>
    > >>> strcmp(s1.c_str(), s2.c_str())
    > >>> and
    > >>> s1.compare(s2)
    > >>>
    > >>> can someone explain what these functions do? It seems that strcmp
    > >>>gives the "right" (i.e.wysiwyg) answer while compare() does not.
    > >>
    > >>'compare' takes into consideration _all_ contents, including any number
    > >>of the "terminating" null characters. 'c_str()' effectively truncates
    > >>the contents at the first null character.

    > >
    > >
    > > Nitpick: it's not c_str() truncating the strings, it's strcmp() only reading
    > > until it finds the first null character.

    >
    > Where is the guarantee that the pointer 'c_str()' returns in _not_ to some
    > temporary buffer that only contains characters up to and including the
    > first null char? Note that if the 'data()' of the std::string does _not_
    > contain a null char, the string _has_ to create a temporary buffer. So,
    > it is _most_ likely that the temporary buffer is created. And if it is,
    > there is no sense for the 'string' to copy anything there beyond the first
    > null character. Hence, the scenario where the 'string' truncates is as
    > equally plausible as the one where it doesn't.


    That was not nitpicking. The standard (well - the draft, but I doubt
    this has changed) says about c_str:
    -1- Returns: A pointer to the initial element of an array of length
    size() + 1 whose first size() elements equal the corresponding elements
    of the string controlled by *this and whose last element is a null
    character specified by charT().

    Also, I doubt that many implementations will allocate a temporary
    buffer. Most will just assure that the buffer always has room enough
    for one extra character and place a null at size() whenever c_str is
    called.

    /Peter
    >
    > V
    > --
    > Please remove capital As from my address when replying by mail
     
    peter koch, Mar 1, 2006
    #8
  9. peter koch wrote:
    > [..] The standard (well - the draft, but I doubt
    > this has changed) says about c_str:
    > -1- Returns: A pointer to the initial element of an array of length
    > size() + 1 whose first size() elements equal the corresponding elements
    > of the string controlled by *this and whose last element is a null
    > character specified by charT().


    You're right, my bad. So, we can safely say that all null characters are
    represented in that array and while 'strcmp' does ignore everything after
    the first null char it encounters, 'memcmp' should be able to compare them
    correctly.

    > [..]


    V
    --
    Please remove capital As from my address when replying by mail
     
    Victor Bazarov, Mar 1, 2006
    #9
  10. Kai-Uwe Bux Guest

    Victor Bazarov wrote:

    > Kai-Uwe Bux wrote:
    >> Victor Bazarov wrote:
    >>
    >>
    >>> wrote:
    >>>
    >>>> For two stl strings s1 and s2, I got different results from
    >>>>
    >>>> strcmp(s1.c_str(), s2.c_str())
    >>>> and
    >>>> s1.compare(s2)
    >>>>
    >>>> can someone explain what these functions do? It seems that strcmp
    >>>>gives the "right" (i.e.wysiwyg) answer while compare() does not.
    >>>
    >>>'compare' takes into consideration _all_ contents, including any number
    >>>of the "terminating" null characters. 'c_str()' effectively truncates
    >>>the contents at the first null character.

    >>
    >>
    >> Nitpick: it's not c_str() truncating the strings, it's strcmp() only
    >> reading until it finds the first null character.

    >
    > Where is the guarantee that the pointer 'c_str()' returns in _not_ to some
    > temporary buffer that only contains characters up to and including the
    > first null char?

    [snip]

    Standard, clause [21.3.6/1].



    Best

    Kai-Uwe Bux
     
    Kai-Uwe Bux, Mar 2, 2006
    #10
  11. Guest

    Thanks! Great discussion.
     
    , Mar 3, 2006
    #11
    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:
    11
    Views:
    1,125
  2. Javier
    Replies:
    2
    Views:
    585
    James Kanze
    Sep 4, 2007
  3. 0m
    Replies:
    26
    Views:
    1,146
    Tim Rentsch
    Nov 10, 2008
  4. fungus
    Replies:
    13
    Views:
    902
    fungus
    Oct 31, 2008
  5. Replies:
    2
    Views:
    547
    Andrew Koenig
    Feb 9, 2009
Loading...

Share This Page