I have converted that one now into a static constant string, but this isn't a solution.
We have discussed already a few times, what to do with such constant strings, e.g. declare them static with some macro tricks or use a string hash. We need a solution for this.
While we need to track down the problem with the string not getting marked properly, generating constant strings is something worthwhile for speed and memory usage reasons. So, let's do this.
1) If need be, we'll have a generic, process-wide constant string pool (I think -- I'm not sure this is needed)
2) We should have a preprocessor for STRING constants
3) The global initialization code will handle allocating and setting up the string constants
We may have issues for strings that need setting up before the encoding/charset/language things they depend on are set, which could be a problem.
As for the macro stuff, I'm picturing something that looks like:
STRINGCONST CONSTNAME "string constant here"
as a declaration. This'll put in an extern declaration in the file in which it is declared, substitute the extern definition for CONSTNAME in that file, and add in an initialization line in the global initialization file. If we're lucky, the system will be sensible enough to detect pre-existing identical string constants and just reuse the string constants rather than recreating them anew each time.
I'm not particularly wedded to the details of the scheme, so if there's a way someone else prefers, that's fine too.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
