Mutable strings are basically a vector< char > like std::string or whatever. They go through a custom allocator which *never frees*. What that means is you can always just take a c_str char * off the string and hold onto it forever.
Thus the readable string is just char *, and you can store those in your hashes or whatever. Mutable string is a String thingy that supports operator += and whatnot, but you just hold those temporarily to do edits and then grab the char * out.
So the usage is that you always just pass around char *'s , your objects all store char *'s, nobody ever worries about who owns it and whether to free it, you can pass it across threads and not worry. To make strings you put a String on the stack and munge it all you want, then pull the char * out and rock with that.
Obviously this wastes memory, BUT in typical gamedev usage I think the waste is usually microscopic. I almost always just read const strings out of config files and then never edit them.
One exception that I'd like to handle better is frequently mutated strings. For example, you might have something in a spawner that does something like this :
for(int variant=0;variant <
numVariants;variant++)
{
// char name[80];
// sprintf(name,"spawnmobj_%d",variant);
String name("spawnmobj_");
name += variant;
Spawn(name);
}
I don't love making names programatically like this, but lots of people do it and it's quite convenient, so it
should be supported.
With the model that I have proposed here, this would do allocs every time you spawn and memory use would increase forever. One way to fix
this is to use a global string pool and merge duplicates at the time they are converted to char *. That way you don't every increase your
memory use when you make strings you made before - only when you make new strings.
With the string pool model, the basic op becomes :
const char * StringPool::GetPermanentPointer( String & str );in which the 'str' is added to the pool (or an existing one is found), and the char * you get back will never go away.
ADDENDUM : to be clear, this is not intended as an optimization at all, it's simply a way to make the programming easy without being too awful about crazy memory use. (eg. not just making String a char [512])
No comments:
Post a Comment