Thread: strings in C++

I've noticed a trend of responses nudging/encouraging people to use of STL strings instead of null terminated char arrays as strings in C++, indicating that STL string class is "the" form of strings in C++ and null terminated char arrays are only for C. While I certainly agree that in general STL strings are easier to use, and should be prefered if a choice is available, I disagree that null terminated character arrays should be shunned in C++.

I wonder how others feel.

While I certainly agree that in general STL strings are easier to use, and should be prefered if a choice is available, I disagree that null terminated character arrays should be shunned in C++.

hmm... but if you agree that std::string should be preferred to null terminated multibyte strings, then would that not mean that, if a choice is available, one should avoid the latter?

My two cents worth:

I think the majority of cases where this "suggestion" is made are clear cases where a newb is trying to use them and they are stumbling around making obvious (to the experienced) mistakes with memory management or buffer overruns or NULL termination issues. In such an instance, especially considering this is the C++ forum and not the C forum, it makes sense to try and nudge them into using a far safer, far simpler alternative. This makes even more sense if the character manipulation isn't the crux of the issue they are trying to solve but rather something that is merely compounding the problems they are having with the code. If they happen to post a bit of code where they are using the character array correctly but having problems with some other aspect of the code then I might not suggest a string since they are obviously experienced to use them correctly. I still might, but I'd hope I'd be less pushy about it. There is usually a good reason to use them when suggested to make ones code cleaner looking and more intuitive which is a great plus for newbs.

It seems to me there's a strong, positive rationale for preferring use of stl containers over corresponding c-style arrays, strings or otherwise. I'm not so sure the reverse can be convincingly argued.

Fair enough, there might be circumstances where a char array might be a viable alternative but for dynamically allocated strings in c++ std::string is surely to be preferred.

Since C-style strings, and functions like strcpy and strcat are part of C++, I don't think it is something to completely sweep under the rug. And learning some of the pitfalls can be helpful. Sure, you can use a std::string quite a bit of the time, but there are still things like sprintf or strftime that can be useful.

Since C-style strings, and functions like strcpy and strcat are part of C++, I don't think it is something to completely sweep under the rug. And learning some of the pitfalls can be helpful. Sure, you can use a std::string quite a bit of the time, but there are still things like sprintf or strftime that can be useful.

Well, those might fall under the category of a choice not being available (or having been ruled out for specific reasons). Consider that opening a file with fstream requires a C-style string.

Originally Posted by laserlight

Well, those might fall under the category of a choice not being available (or having been ruled out for specific reasons). Consider that opening a file with fstream requires a C-style string.

But one can be made available using std::string.

Code:

   std::string filename("file.txt");
   std::ifstream file(filename.c_str());

But one can be made available using std::string.

Ah, but if I remember correctly the reason was so that one could deliberately avoid using std::string in that context, if necessary.

Are you talking about how you're supposed to avoid using STL coontainers with C functions? I'd agree, but in the case of opening a file there isn't much of a choice here. open's first argument is a character pointer.

No. What I meant is that in this case, by design, std::string is not necessary.