What is the problem with the code?

[dullboy]

Yes, Joeman's suggestion does allow expressions such as: "hello" + str, but the definition of operator+ will expose char* to clients. I just don't like this idea. Basically my goal is that clients shouldn't see char*. I expect that you may pass char* to my original defintion of operator + and at the mean time char* will be IMPLICITLY converted to MyString. But obviously when a char* is on the left hand side of +, it failed to be converted to MyString. That is my question. How'd I make it possible. Thanks for your inputs.

Why not? It looks like you are giving operator+ the semantics of operator+=, which is a Bad Thing. Furthermore, your implementation of operator+ does unnecessary work: you should just create a buffer for the result, copy over what is necessary, then destroy a's contents and then make a's pointer point to the start of the new result buffer. (Of course, this would be after you have changed this to operator+=.)

EDIT:

Joeman's suggestion will allow expressions such as: "hello" + str. I do not see how that violates intuition. But what I had in mind was changing your current operator+ to take its first argument by const reference. This would also allow expressions such as "hello" + str, except that it will likely be less efficient than providing an overload of operator+ with a const char* first parameter.

[laserlight]

but the definition of operator+ will expose char* to clients.

What do you mean by that?

I expect that you may pass char* to my original defintion of operator + and at the mean time char* will be IMPLICITLY converted to MyString.

Yes, and as I noted this would be possible if you changed the declaration to:

MyString operator+(const MyString& a, const MyString& b);

Note that the first parameter is also a const reference. Alternatively, the first parameter could be a value, so you could write:

MyString operator+(MyString a, const MyString& b)
{
    return a += b;
}

Making use of operator+=, which you would overload yourself to have an implementation similiar to what you currently have for operator+.

But obviously when a char* is on the left hand side of +, it failed to be converted to MyString.

That is the whole idea behind adding an additional overhead (or two) involving const char* parameters: you want to avoid the implicit conversion to MyString, as that has a cost attached to it.

[dullboy]

If I change first parameter of operator+ to a const, then it doesn't compile because I need to modify it within body of operator+. Thanks for your inputs.

What do you mean by that?


Yes, and as I noted this would be possible if you changed the declaration to:

MyString operator+(const MyString& a, const MyString& b);

Note that the first parameter is also a const reference. Alternatively, the first parameter could be a value, so you could write:

MyString operator+(MyString a, const MyString& b)
{
    return a += b;
}

Making use of operator+=, which you would overload yourself to have an implementation similiar to what you currently have for operator+.


That is the whole idea behind adding an additional overhead (or two) involving const char* parameters: you want to avoid the implicit conversion to MyString, as that has a cost attached to it.

[laserlight]

If I change first parameter of operator+ to a const, then it doesn't compile because I need to modify it within body of operator+.

That's right. operator+ should not modify its first argument. Rather, you should create an operator+= instead, and use that to implement operator+.

Put it another way: a = 2, b = 3. c = a + b. What is the value of a? According to you, the value of a is now 5. Does that make sense to you?