Strings and Resource Files

[dwyer.bill]

My boss insists that whenever we use a string we place it in a resource
file every single time. This goes for error string that are displayed
through a message box, constants, ect. He claims that this adds a huge
performance boost in the application but I don't understand why. Is
there something to this?


Bill

 

[Oenone]

My boss insists that whenever we use a string we place it in a
resource file every single time. This goes for error string that are
displayed through a message box, constants, ect. He claims that this
adds a huge performance boost in the application but I don't
understand why. Is there something to this?

I don't believe so. My expectation is that you and right and your boss is
wrong (don't you just love bosses?). Using "hard coded" strings, the
compiled code simply refers to the address of the string in the
application's memory space. Using resource files, you would have to use
extra code (= slower) to extract the string from the resource data into a
local variable, and then use that.

If I'm wrong here, I'm sure someone will be along to correct me very
shortly.

There are some good reasons for using resource files for all your strings:

- it makes it vastly easier to localise your application for different
languages. If you want to be able to run it in French, just give the string
resources to a translator and they'll give you back a French translation.
These can then (in theory) be slotted back into a second resource file, and
switching languages is simple.

- it allows non-developers to write and maintain the messages that get
displayed in your application without having to wade though pages of
impenetrable code (which they will most likely introduce syntax error into,
too).

However, if neither of these are relevant and unlikely to become so, IMO
you'd be better off hard coding the strings. Convincing your boss may be
another matter though...

 

[Marina Levit [MVP]]

While it's hard to imagine this being more performant, it does have the
benefit of taking out hard coded strings out of your application. If you
need to fix or change a message, you need only change the resource file. If
you need to support multiple languages easily then you've got the resource
files for that as well.

 

[dwyer.bill]

Alright that makes sense. Your reasons for this method are good but
it isn't really applicable for what I am doing. But the rational for
maintaining the messages by a non-developer might give me enough
motivation to do it without grinding my teeth, given that it might be
useful in the future. I just find myself having to "double document"
things. Once in the resource file and then one in the comments.
Before I started doing that I would have to switch to the resource file
a couple times just to find out what was going on in a procedure.

Thanks for the feedback.

Bill

 

[Chris Mullins]

My boss insists that whenever we use a string we place it in a resource
file every single time. This goes for error string that are displayed
through a message box, constants, ect. He claims that this adds a huge
performance boost in the application but I don't understand why. Is
there something to this?

I'm afraid your boss is a bit confused.

While it's great that he's enforcing this as a coding standard upon you
guys, the only real reason to do it is for either multi-lingual
applications, or applications where you'll need to change messages without
recompiling.

It's actually imposing a performance hit - string access is now being forced
through a resource manager, which is then having to determine your regional
setting, probe for satallite assemblies, and finally return a string from a
resource file.

Compare this to: string s = "test";

Obviously, the 2nd case there is going to far outperform the 1st.

Now, performance aside, you should put your strings in a resource file. It's
a good habit to be in.