Sign in to follow this  

a woefully n00bish C++ question....

This topic is 4418 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Most of the time, you'll want to use std::string. Should a function expect a char*, use the c_str() method. char* have many issues, and there aren't many advantages in using them.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by JDUK
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.


The fact that you won't have to worry about the memory when there's no need to is reason enough for me. There are other reasons, of course. I'm sure google will convince you. [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by jfclavette
The fact that you won't have to worry about the memory when there's no need to is reason enough for me. There are other reasons, of course. I'm sure google will convince you. [smile]


I think you give the masses too much credit. I've seen many (many) people talking about the slowness of strings, and advising char* instead. We have it drummed into us here at Gamedev by the heavyweights (Zahlman's sig in particular), but other people aren't so lucky.

And yes, in C++ it's preferable to use std::string, simply because it's safe and easy, and in most cases (I say most cases, hashmaps are an one of the few exceptions) it's equally as fast as char*, if not more so due to the code-fu the STL implementors have written.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4418 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this