Static strings: string or char*?

Started by
16 comments, last by Trap 19 years, 4 months ago
I've started using STL strings in my code for security, and love how easy they are to use. But what about static read-only strings? Like, lets say you have a hard-coded array of text strings, that are never modified, just read. Would you go so far as to make them string objects as well, or is char* sufficient in this case? Maybe strings can't even be used in that way, I don't know. I'm assuming char* is safe enough if the string length is known? Or am I missing something?
Advertisement
If the strings never change size (almost the only thing string's gain you), then char*'s are fine.
You can use std::strings like that, but it's largely pointless, and may fragment your heap somewhat. Just remember that, if you need it, you can convert a char * to a string object and think happy thoughts.
Write down this equation in your compiler, run and think if such memory overhead when using X sized array of strings can be accepted.

std :: cout << sizeof(std::string) * X << endl;

If you're writing program or small game, odds are that you shouldn't care so much about performance ("Premature optimization is the root of all evil" etc.), but if you're writing game, and this game must run fast on a variety of comptuers... that's different situation.

-------

As for me, I'm using std::strings in case when I've got need to do sth more complicated with it; also remember that strings are neat and handy, but they come with a price and if you care about performance you should be carefull, ie. don't EVER pass them as function arguments:

void function(const string & _blablabla);

instead use:

void function(const char * _blablabla);


and if you need to do sth with _blablabla then simply:


void function(const char * _blablabla)
{
string foo(_blablabla);
...
}
just out of intrest, why would you use it like that? I'd have thought that passing a const std::string& would be more logical, there is no copy of the string made, where as on the 2nd method you have to make a function call to get the address of the string back and on the 3rd version you have to make that same call THEN construct a new string to use AND destroy said string at the end of the function.

Now, call me daft, but isnt that going to increase the overhead alot more vs just passing a const std::string& in?
Quote:Original post by _the_phantom_
Now, call me daft, but isnt that going to increase the overhead alot more vs just passing a const std::string& in?

Shhh, common sense is never as fun as dogma!

Seriously though, if you're gonna mess with the string (searching/appending/trimming/etc) put it in a string class. If you're just passing it around, do whatever's easiest.

I have browsed the Netscape Gecko sourcecode, and they have several string classes:
* weak pointers to strings (char* wrappers)
* small strings (allocates from a 64KB buffer)
* strong pointers to strings (char* wrappers)
* ropes (for large strings)

Iterators are used to traverse the strings so the differences aren't noticeable unless you are making OS calls.

[Edited by - antareus on December 1, 2004 9:37:05 AM]
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
when you do a line like this:

char myString[] = "some message";

remember that the buffer is a copy and is not constant, but when you do this:

char *myString = "some message";

the buffer is a constant char array and you CANNOT modify it (you will get either compile time warnings or runtime errors) ... so it is much better to be explicit about this and write:

const char *myString = "some message";
I use std::string a lot, in fact for any and all text manipulation I do unless I see a major reason not to. - but I use 'const char *' when initializing compile time constant strings. And since you can create const char * from strings and strings from const char *, then it's no problem.
explain why void someFunc(const string& s) {} would be bad?
the string is passed as a reference and not as a copy plus it's more elegant, makes more sense, less errorprone/more typesafe than passing char*.
Quote:Original post by Anonymous Poster
explain why void someFunc(const string& s) {} would be bad?
the string is passed as a reference and not as a copy plus it's more elegant, makes more sense, less errorprone/more typesafe than passing char*.


And when you pass "const char *" you'll get a string automatically anyway.

This topic is closed to new replies.

Advertisement