5

In C++03, for std::string class, c_str() and data() methods have a different behavior.

The first returns a null-terminated character array and the management of this last is totally dependent from the implementation. Indeed, c_str() could return a pointer to another pre-allocated buffer, which always contains a null-terminated string, but this is not mandatory. However, the complexity must be constant.

The second one simply returns the pointer to the internal buffer of std::string, which could be null-terminated, or not.

Thus, in C++03, you could guess that a cast operator to const char* is not a good idea. Indeed, the expected behavior, most of the time, is to have a null-terminated C-style string, but, as the implementation of c_str() could vary, there could be an hidden overhead behind the cast operator. In the other case, it could bring confusion if the cast operator returns the same resultat as data().

However, for C++11, c_str() and data() have the same behavior. c_str() returns a pointer to the std::string object internal buffer. A cast operator to const char* is no more ambiguous. Why this method is not present in std::string class in C++11 ?

Thanks !

Improve this question
12
  • 1
    Devil's Advocate: Why should it be? Commented Jul 30, 2014 at 22:31
  • 5
    Why would we want one? c_str or data is more readable than an explicit cast and an implicit cast would cause so many problems. Commented Jul 30, 2014 at 22:32
  • 1
    Because it is a useful method and not just "sugar code" ? Always call c_str() when you need a const char* is boring. @chris: what kind of problems ? Commented Jul 30, 2014 at 22:33
  • 1
    @PaulMcKenzie: In the Qt library, for example, QByteArray has a cast operator to const char*, and I do not see what is the problem with that. Commented Jul 30, 2014 at 22:39
  • 3
    @AntiClimacus - I am in Matt McNabbs neighborhood of thinking. Every class I've seen developed with casting operators winds up doing something unexpected in non-trivial code. stackoverflow.com/questions/492061/… Commented Jul 30, 2014 at 22:48

2 Answers 2

Reset to default
3

Your question is fundamentally about the philosophy behind the design of the string class. I can but opine.

Why should string have a cast operator to const char*? Cast operators are syntactic sugar for other operations, and are truly needed only in unusual circumstances. Really, they are never needed -- you can always accomplish the same goal in another way.

string already does provide the means to interract with old C-style interfaces, via c_str and data. Adding a cast operator in to the mix doesn't add functionality and does add complexity to the class. Moreover, using a cast operator is always semantically murky. In call-site code, a cast such as with static_cast <const char*> is generally expected to be a compile-time operation. By performing this cast through run-time code, you ambiguate your code. It's not as clear. Because the expectations and reality aren't the same, it's much easier to misuse this run-time cast than the compile-time equivalent.

I would argue that there should not be an implicit conversion operator anywhere it's not truly needed; and it isn't here.

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

I'd also add Drew's point: dangling pointers are encouraged with an implicit conversion. Some STL areas have been designed in order to avoid common pitfalls.
Where does the OP say the cast operator shall be implicit? Also, there's an easy way to restrict it to non-temporaries.
@Deduplicator: Well, I guess he doesn't. But at the same time he hasn't said it should be explicit. I still don't see the necessity either way.
@Deduplicator The problem exists with non-temporaries. With two lvalues, you still have one dependant on the lifetime of the other.
@JohnDibling: Thanks. I understand the STL philosophy, but C++ philosophy is also allowing a useful feature is more important than preventing every possible misuse of C++, and all your responses are about misuses, dangling pointers, thread safety, etc. These errors could be done with the pointer returned by c_str(), too. Furthermore, if it is not a good idea to use a cast operator, because casts are expected to be at compile-time and not at runtime, when could I use a cast operator ? What could be a good case to use it ?
|
1

The main reason for these changes was thread safety and in particular avoidance of invalidating iterators and references. For this to happen required null terminating buffers.

More can be read on the proposal N2534.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.