Why does the following not invoke the overloaded operator== (const String &, const String &)?
"cobble" == "stone"
views:
169answers:
4
+5
A:
Because implicitly existing operator==(char*, char*) matches your usage of == better.
The operator == in code "cobble" == "stone" can be matched in different ways: operator==(char[], const String&), operator==(const String&, String), operator==(const String&, const std::string&) etc., provided that the conversion from the parameter type (char*) to the type of arguments (String*, etc.) exists. However the usual char* comparison matches the input best of all.
Vlad
2010-04-22 12:33:57
surender
2010-04-22 12:44:40
@Vlad: Conversion from a string literal to `char*` are deprecated and should not be used. You should use `const char*` instead.
sbi
2010-04-22 12:48:52
The operator ==(char*, char*) is always implicitly provided by the compiler. This way you can compare pointers :-) It just compares the pointer values, not strings.
Vlad
2010-04-22 12:49:43
sbi
2010-04-22 12:51:15
@vlad can u answer my second question?
surender
2010-04-22 12:51:40
Vlad
2010-04-22 12:52:33
@sbi: I assumed OP means some custom class with string semantics.
Vlad
2010-04-22 12:53:07
@Vlad: ...if these conversions are _implicit_.
sbi
2010-04-22 12:53:47
@Vlad: So did I, until the OP wrote `string`. Now I'm not sure anymore.
sbi
2010-04-22 12:54:24
@sbi: yes, indeed.
Vlad
2010-04-22 12:55:06
i have written following codeif("cobol" == str)// str is object of my slef made class Stringi have written bool operator == ( char *str1, String as well but it showing error can u explain?
surender
2010-04-22 13:07:03
@surender: It would be easier to answer if you asked that in a new question? Include the (relevant) code for your `String` class, the code showing the `if` statement that you are trying to do, and details about the error that you are receiving.
Matthew T. Staebler
2010-04-22 13:17:01
@surender: which is the error message? Maybe you can expand your original answer and post your code there?
Vlad
2010-04-22 13:56:06
+5
A:
Because those are simple sequences of characters as in C but no instances of the string class.
Joey
2010-04-22 12:33:59
+11
A:
Because in C++, string literals are of the type const char[] (also called a zero-terminated string constant), not std::string, let alone String (whatever that is). The fact that string literals are character arrays we inherited from C.
There's a built-in operator== comparing two char* by comparing their addresses. Since arrays are implicitly convertible into pointers to their first elements (due, you guessed right, the C heritage), this operator steps in and what you compare are the addresses of these literals in memory.
Supposing your String class has an implicit conversion constructor from const char* (String::String(const char*)), you could convert one of the two to String. The other string would then be converted implicitly:
String("cobble") == "stone"
(Unless overloads of operator== taking a String and a const char* are provided for efficiency. If they are provided, they step in.)
sbi
2010-04-22 12:37:26
"We inherited this from C" -- we did not. In C they were char[] without being const. Modifications were either undefined or otherwise dangerous, but were allowed syntactically because of historical reasons.
Windows programmer
2010-04-23 08:04:22
sbi
2010-04-23 09:23:21
"Correct me, please, if I'm wrong." -- You already were corrected and here is a repeat. 6.4.5 in the C standard, "the array elements have type char" without saying const.
Windows programmer
2010-04-26 00:31:44
@Windows programmer: I haven't found anything in this thread quoting from 6.4.5., so I'm not sure where you think I already have been corrected regarding this. Anyway, I don't have a copy of the C standard to check this for myself, so I take your word for it that the above applies to string literals, and not to character arrays in general.
sbi
2010-04-26 06:33:34
2 days prior to this comment, my first comment said "In C they were char[] without being const". I didn't bother looking it up that time. 6 hours prior to this comment I looked it up, found it in 6.4.5, and quoted from it. 6.4.5 is the section on string literals. sbi has been corrected twice.
Windows programmer
2010-04-26 07:11:23
@Windows programmer: re "sbi has been corrected twice": I've had my share of corrections and I'm Ok with ti. If you feel great about correcting me twice, I'm fine with it. `<shrug>` I did say that my C is rusty. (And that was an understatement. I've always been a C++ programmer.) And I'm amazed at C's ignorance regarding `const` correctness. Anyway, my main point was that we inherited from C string literals being zero-terminated character arrays instead of `std::string` objects. Whether those arrays are `const` or not doesn't change that main point. Still, I will go and disambiguate my answer.
sbi
2010-04-26 08:07:24
"so I'm not sure where you think I already have been corrected regarding this" -- so I showed you where, so you insult me, sheesh. "And I'm amazed at C's ignorance regarding const correctness" -- When C was invented it had string literals and it did something with them. The const keyword came along 10 years later. Someone figured it wouldn't be worth breaking millions of existing programs to force editing their declarations to become const correct.
Windows programmer
2010-04-27 00:52:21
@Windows programmer: If you felt insulted, then be assured it wasn't my intention. I don't even have any idea _where and when_ I insulted you. I apologize nonetheless.
sbi
2010-04-27 07:54:54
@sbi, "If you feel great about correcting me twice" -- This is quoted in order to show where and when, but don't worry, I accept your apology.
Windows programmer
2010-04-27 09:01:38
A:
"cobble" ist interpreted as a char*, and the compiler uses pointer comparison to compare char*. If you want to compare the contents of the strings, use
std::string("cobble") == std::string("stone")
instead, and the compiler will use operator== (const std::string &, const std::string &).
Danvil
2010-04-22 12:38:52
Another answer says string literals are char[]. Is it char* or char[]? Does it matter?
AshleysBrain
2010-04-22 12:43:02
@Danvil Nope. @Ashleys: String literals have the type `const char[N]`, for some `N`. As you may know, arrays can decay to pointers, and in this case they can decay to `const char*`. There's also a *deprecated* conversion from `const char*` to `char*` which, if modified, leads to undefined behavior. String literals are certainly not `char*`'s.
GMan
2010-04-22 12:55:11
@GMan: I agree with everything, except: Isn't the deprecated conversion from an revalue of `char[]` (aka a string literal) to `char*`?
sbi
2010-04-22 13:03:39
With a parameter to a function, you always get a pointer even if you use array notation. `foo(char x[])` is exactly the same as `foo(char* x)`.
Danvil
2010-04-22 13:53:26
@sbi: Taking into account @John's correction, yes, I messed up. I meant a string literal can be converted to a `char*` (which is seen as a conversion to `const char*`, then to `char*`.) 4.2/2.
GMan
2010-04-22 14:12:55
@John: ISTR that string literals are rvalues of `char[]` in the same sense that `42` isn't a `const int`, but an rvalue of `int`. Not that this would make much practical difference...
sbi
2010-04-22 14:30:53
@GMan: I don't think you can implicitly convert `const char*` to `char*`. That exception was made explicitly for converting string literals (rvalues of `char[]`) to `char*`, because much of old C code didn't pay attention to const-correctness.
sbi
2010-04-22 14:32:45
@sbi: Just looked it up in my copy of the standard. 2.13.4.1: "An ordinary string literal has type “array of n const char” and static storage duration (3.7), where n is the size of the string as defined below"
John Dibling
2010-04-22 14:41:13
@sbi: integral literals are `int` however, just as you said. I think what may have thrown you off is that the standard treats `int` literals and string literals differently WRT const-ness.
John Dibling
2010-04-22 14:46:27
@John: I stand corrected then, a string literal is indeed of the type `const char[]`. Thank you for looking this up. I just wish I would remember that...
sbi
2010-04-22 21:05:40