Strings and Resource Files

12 Dec 2006 8:41 PM

dwyer.bill@gmail.com

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

12 Dec 2006 9:05 PM

Oenone

dwyer.b***@gmail.com wrote:

> 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...

--

(O)enone

13 Dec 2006 6:58 PM

dwyer.bill@gmail.com

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

Oenone wrote:

Show quoteHide quote

> dwyer.b***@gmail.com wrote:
> > 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...
>
> --
>
> (O)enone

12 Dec 2006 9:15 PM

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.b***@gmail.com> wrote in message
Show quoteHide quote

news:1165956115.268959.267610@j72g2000cwa.googlegroups.com...
> 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
>

14 Dec 2006 2:02 AM

Chris Mullins

<dwyer.b***@gmail.com> wrote:

> 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.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins