Post a Comment On: cbloom rants

So I wrote a little exe to extract static strings from code. It's very simple. StringExtractor just scans some dirs of code and looks for a tag which encloses a string with parens. eg. : MAKE_STRING( BuildHuff ) it takes all the strings it finds in that way and makes a table of indexes and contents, like : enum EStringExtractor { eSE_Null = 0, eSE_BuildHuff = 1, eSE_DecodeOneQ = 2, eSE_DecodeOneQ_memcpy = 3, eSE_DecodeOneQ_memset = 4, eSE_DecodeOneQuantum = 5, ... const char * c_strings_extracted[] = { 0, "BuildHuff", "DecodeOneQ", "DecodeOneQ_memcpy", "DecodeOneQ_memset", "DecodeOneQuantum", ... it outputs this to a generated .C and .H file, which you can then include in your project. The key then is what MAKE_STRING means. There are various ways to set it up, depending on whether you are replacing an old system that uses char * everywhere or not. Basically you want to make a header that's something like : #if DO_STRINGS_RAW #define MAKE_STRING( label ) (string_type)( #label ) #define GET_STRING( index ) (const char *)( index ) #else #include "code_gen_strings.h" #define MAKE_STRING( label ) (string_type)( eSE_ ## label ) #define GET_STRING( index ) c_strings_extracted[ (int)( index ) ] #endif (string_type can either be const char * to replace an old system, or if you're doing this from scratch it's cleaner to make it a typedef). If DO_STRINGS_RAW is on, you run with the strings in the code as normal. With DO_STRINGS_RAW off, all static strings in the code are replaced with indexes and the table lookup is used. It's important to me that the code gen doesn't actually touch any of the original source files, it just makes a file on the side (I hate code gen that modifies source because it doesn't play nice with editors); it's also important to me that you can set DO_STRINGS_RAW and build just fine without the code gen (I hate code gen that is a necessary step in the build). Now, why would you do this? Well, for one thing it's just cleaner to get all static strings in one place so you can see what they are, rather than having them scattered all over. But some real practical benefits : You can make builds that don't have the string table; eg. for SPU or other low-memory console situations, you can run the string extraction to turn strings into indeces, but then just don't link the table in. Now they can send back indeces to the host and you can do the mapping there. You can load the string table from a file rather than building it in. This makes it optional and also allows localization etc. (not a great way to do this though). For final builds, if you are using these strings just for debug info, you can easily get rid of all of them in one place just by #defining MAKE_STRING and GET_STRING to nulls. Anyhoo, here's the EXE : stringextractor.zip (84k) (stringextractor is also the first cblib app that uses my new standardized command line interface; all cblib apps in the future will have a common set of -- options; also almost all cblib apps now take either files or dirs on the command line and if you give them dirs they iterate on contents). (stringextractor also importantly uses a helper to not change the output file if the contents don't change; this means that it doesn't mess up the modtime of the generated file and cause rebuilds that aren't necessary). Obviously one disadvantage is you can't have spaces or other non-C-compatible characters in the string. But I guess you could fix this by using printf style codes and do printf when you generate the table.