C-strings Vs Strings in C++

Hey all, first post.

So, i'm a newbie and working my way through C++ without fear. I've noticed that through the book the author has been declaring and intializing string variables in this way

char *new_string = "Freem";

I've got to the chapter on strings and have noticed that there is a lot of emphasis on c-strings and not the 'new' string type which declares and initializes like this.

string new_string = "Freem";

I've used java a little bit in the past and pre-C++ without fear have done have always used the 'new' string type.

What is the benifits of c-strings. I like the new string type and feel comfortable with it - should i continue with that or should i stop and start using the c-strings?

Thanks in advanvce

I consider the std::string type to be superior. That doesn't excuse not knowing about character arrays, but you should use std::string as much as you can (or some other string object). In particular, C-strings are good to know about because you'll encounter them, regardless, and some methods like fstream::open() actually use C-strings.

Code:

char *new_string = "Freem";

C-string vs std::string aside, this is just plain wrong. (Well, deprecated. But still wrong.)
Never assign a string literal to a pointer to non-const. The correct way to write this is:

Code:

const char *new_string = "Freem";

Char arrays can be useful in some ways, strings are quicker to use.

The only thing I find much less awkward with c-strings is reading different data types in or out; what you can do in one simple line with sscanf/sprintf, done with std::string requires a new object (a stringstream) plus repeated, separate calls to its methods for setting precision, field width, etc, and adding/extracting one item at a time. Even so, when working in C++ I use std::string except where impossible.

Conversely, std::string is a lot less awkward for working with data of arbitrary and uncertain length.

Other than that, I don't find them very different. You probably do have to learn both of them anyway because there are many basic situations that require one but not the other.

Originally Posted by MK27

Conversely, std::string is a lot less awkward for working with data of arbitrary and uncertain length.

Other than that, I don't find them very different. You probably do have to learn both of them anyway because there are many basic situations that require one but not the other.

C-strings are pure arrays while std::strings are object-oriented, what makes them two totally different interfaces.

std::(w)string should always be prefered, unless there is a specific reason.

Originally Posted by CornedBee

C-string vs std::string aside, this is just plain wrong. (Well, deprecated. But still wrong.)
Never assign a string literal to a pointer to non-const. The correct way to write this is:

Code:

const char *new_string = "Freem";

I know it is true, however, I have found an example in the C++0x standard with such an assignment.
Have a look at the example in 9.5.5 (unions), it says:

Code:

void f() {
union { int a; char* p; };
a = 1;
p = "Jennifer";
}

Could somebody explain it to me?

Originally Posted by kmdv

C-strings are pure arrays while std::strings are object-oriented, what makes them two totally different interfaces.

Yes but that is a very superficial syntactical difference, IMO, and I am perfectly comfortable with both "interface styles", so that is more or less a non-issue (for me, and probably lots of other people too):

Code:

doSomething(myArray, param);  // array function syntax.
myObject.doSomething(param);  // OO syntax, OMG.

std:w)string should always be prefered, unless there is a specific reason.

Agreed, and I said that explicitly. "Specific reason" to me is usually: low level C API making it impossible to not use a c-string at various points, in which case I am not going to turn a char* returned into a std:string then turn it back into a c_str() as it is passed around, that is like driving in concentric circles toward your destination. I recognize there are some C++ wrapper API's that do more or less exactly that, which is why I said: you might as well learn both of them so you do not have to depend on wasting resources to work around your weaknesses.

Originally Posted by kmdv

p = "Jennifer";
Could somebody explain it to me?

Since "a" is not const and it is a union there is no point in "p" being const.

Code:

doSomething(myArray, param);  // array function syntax.
myObject.doSomething(param);  // OO syntax, OMG.

O_o

Syntax has nothing to do with design methodologies.

You can't tell if either or both of those lines invoke some "OOP" construct.

The first call could just as easily be "OOP" using strait C interfaces.

The second call just as easily be an "I'll just put this here for my convenience." situation where `??? doSomething(???)' represents a function pointer.

In the case of `std::string' versus `char *', the argument could be made for syntax differences, but that isn't what makes it "OOP" or not. The `std::string' object maintains state and supports methods that mutate that state. The `char *' version has state and functions that mutate that state. The difference is that the `std::string' object maintains more state that is relevant to the nature of the construct it represents than the `char *' version. For example, the `std::string' object automatically mutates the associated length of the string. The `char *' version does not maintain such additional state. A C programmer could easily wrap a `char *' up with a structure and create a few functions that operate on that structure to maintain similar state. The necessary syntax differences of the C version doesn't magically imply that the resulting structure and operations are not following "OOP" principles.

So, yea, your logic here is just as bad as the "OOP" purists who think free functions break "OOP" principles.

Friendly and powerful syntax is nice and extremely useful, but syntax alone doesn't make a thing conform to principles and methodologies of a programming "paradigm".

Soma

Originally Posted by MK27

...Agreed, and I said that explicitly. "Specific reason" to me is usually: low level C API making it impossible to not use a c-string at various points, in which case I am not going to turn a char* returned into a std:string then turn it back into a c_str() as it is passed around, that is like driving in concentric circles toward your destination...

Just pointing out that you can replace char arrays with std::vector and avoid C-style strings altogether. It works great for when you need dynamic length C-style strings (ie buffers).

Originally Posted by MK27

The only thing I find much less awkward with c-strings is reading different data types in or out; what you can do in one simple line with sscanf/sprintf, done with std::string requires a new object (a stringstream) plus repeated, separate calls to its methods for setting precision, field width, etc, and adding/extracting one item at a time...

Boost.Format fixes that (out)! It's a shame there's no such thing in the standard, though.
And boost::lexical_cast fixes type conversions for many things. Reading in specific types can already be done with std::cin >>.

Originally Posted by kmdv

I know it is true, however, I have found an example in the C++0x standard with such an assignment.
Have a look at the example in 9.5.5 (unions), it says:

Code:

void f() {
union { int a; char* p; };
a = 1;
p = "Jennifer";
}

Could somebody explain it to me?

Interesting. Especially since the C++03 standard already contains exactly this example. Once I get my main computer back I can check the FDIS (they've since locked it down). Anyway, this should be submitted as an editorial defect.

Originally Posted by CornedBee

Once I get my main computer back I can check the FDIS (they've since locked it down). Anyway, this should be submitted as an editorial defect.

In the FDIS, p is now const char*, not char*

I think that has been fixed for a while. The latest draft I have is from February; it is fixed in that draft.

they've since locked it down

I know you can get the latest draft papers with draft numbers and difference formatting, but I didn't know they ever released "FDIS" level papers with "FDIS" formatting. (Though from what I'm told, the latest draft equivalent is exactly the same as the "FDIS" except where the markup noting the differences between drafts has been omitted.) It was my understanding that the practice was even against ISO rules.

Soma

N3290 is the FDIS, N3291 is the final draft. But now both of them are locked down. The most recent version you can get is N3242, which is what you have.
But for a few weeks directly after the mailing was published, both N3290 and N3291 were freely available. This may have been just an admin mistake, but whatever.