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

[lchian]

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.

 

[Victor Bazarov]

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

 

[Default User]

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

 

[Victor Bazarov]

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

 

[Default User]

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.

 

[Kai-Uwe Bux]

'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

 

[Victor Bazarov]

Victor Bazarov wrote:




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

 

[peter koch]

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

 

[Victor Bazarov]

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

 

[Kai-Uwe Bux]

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

 

[lchian]

Thanks! Great discussion.