Hi, im currently making the transisition from C# to C++ for my games programming and have stumbled across a bit of a newbyish void in my C++ knowledge. When should i use: "std::string myWord" instead of: "char *MyWord" ? in C# i just used strings to store words and after a few tutorials in C & C++ im using char * to store them in C++ but there are still strings in C++... so how do i work out the right tool for the job? Cheers

They're used for the same purposes, but string amplifies the C++ feel because its OO and contains several methods to manipulate it. Using char *c; is more of a C feel, and it depends on headers that have functions outside of any class.

ahh right so a *char is just used for holding an array of characters to make a word.
And a strings got all the funky built in deeleys for manipulation, validation, etc, etc??

so for just passing text to functions or temproreraly storing words *char is fine?

Quote:Original post by jfclavette
Most of the time, you'll want string. Should a function expect a char*, use the c_str() method.

Cheers, could you please elaborate as to why i would want to use MyWord.c_str()
over a *char ?

just so i know why im doing what i should be doing ;)

Thanks.

Cool, thanks :)

You should use char* when you need:

- A pointer to a fixed size buffer of characters, either because you are receiving data a chunk at a time from somewhere like a network socket (typically this would be binary data, and typically you should try to find a library that does this part and lets you work at a higher level), or because the data really represents some set of characters that has to be a specific size, and doesn't really represent text (for example, an array of characters being used to create screen graphics at the console). In these cases, it should be ok (even if it never happens) to have '\0' as a character in there, and you should not be using strlen() at all (if you are reading data into a buffer and it doesn't necessarily fill the buffer, you still don't need strlen(); these APIs generally tell you via the return value how many chars were read, and some do NOT null-terminate the buffer).

- A constant string, e.g. an error message (although these usually shouldn't be hard-coded anyway)

Or:

- When you have already received a char* (a string literal perhaps representing a file name, or a command-line argument) and you are 100% sure you will not need to do any processing on it that could possibly change the length.

In other situations, prefer std::string. It will save all manner of headaches. The flip side of "you get to do your own memory management" is "you have to do your own memory management"; and who really *likes* that stuff anyway? It will also be faster than using char*'s for certain tasks when they are written in a normal way, because the string length is cached. You can of course cache this value working with a char* and avoid multiple strlen() calls, but it is harder to remember and less organized (you end up having to pass the cached value across functions, update it etc. Much better to encapsulate that in a struct. Having done that, much better to use the RAII paradigm to handle the memory management. Having done that, much, much better to use the standard library version rather than your own hack). In normal situations it will still be as fast in release mode, because element accesses can be inlined and optimized into char array element accesses.

I don't really see how char*'s could be faster for hash maps, unless perhaps you are abusing object identity vs. object equality and just using the address for a hash. I can see the value in a 'symbol' class wrapping a char* and used for keys into a hash table (or a tree-based map) - by string pooling, it would become valid to compare pointers for object equality (see java.lang.String.intern()). Perhaps I will write it up later.