The African Chief wrote:
As Pierre said: string comparison are less efficient than integer compares, and generally I think *internal* things (i.e. things that must only be read by computers, not by humans) should use integers rather than strings when there's no real need for strings. Resource files, AFAIK, are binary files, anyway, so what good would it be to have some strings scattered in them?
Resource files (at least Windows resource files) can also hold strings in string tables. Most Windows programmers cannot do without these string tables. How would you represent the strings with integers? You need to store the actual strings in the resource file.
That's something different! These strings (if I understood string tables correctly) are actually to be read (or typed) by humans. There's no question that they must be stored as strings (unless, of course, one intentionally wants to encrypt and/or compress them to make them unreadable in the binary). But e.g. the IDs of the strings would be numerical (just as they are in WinAPI/OWL, AFAIR).
Would there be a problem if two or more programmers (unknown to each other) just happened to choose the same ID?
As I described elsewhere, one could use some bits of the ID as a "programmer ID" and make it at least very improbable that ever two programmers would choose the same bits. Unless this would happen, all IDs by all programmers would automatically be different.
I am just asking, because I am not sure whether this will affect anything else or not (it may very well not affect anything).
If different programmers really happened to choose the same ID, it could matter if they wanted to combine their sources (however, the compiler would (should) notice this, so they could change the IDs, and they'd just have to recompile everything once), or when they exchanged or shared data files with these IDs in them (which, however, seems strange unless the sources are combined, too).