Public shared functions or public properties for "global" strings

[WannaFly]

Using .NET:
In my winforms application i have about 10-15 global strings that are used for various settings.

I've contemplated moving them into a class, but we're debating which to do:

a shared function or a public property.

Shared function benefit: doesnt stay in memory.
Public readonly property: code only run once.

The strings are determined by very simple string concatenations:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) & "\MyProgram\"

One of them is the path to save files, so it gets run every few minutes when the user saves the document.

So, which would be "better"? I know it's up to opinion most of them time but I'm looking for something I might've overseen.

 

[Markbnj]

I'm not sure I see the difference, and I suspect that the get_ accessor would compile down to pretty much the same CIL as your public function. As for memory usage, I don't see the difference there either. Both the function and the get_ accessor will return a string object that will remain in memory as long as there are live references to it.

Am _I_ missing something?

Properties gets vs. functions that return the same value seems like a syntactic nicety to me (as so much of C# is now). I figure if you're going to drink the koolaid then use properties for values that are... well... properties. Not very helpful I guess.

 

[degibson]

Shared functions require memory, too -- instruction memory instead of data memory. I'm also not entirely clear how you can make literal strings disappear with accessor methods... they're still literal strings somewhere.

When in doubt, do whatever makes you feel less like you need to shower at the end of the day.

 

[PhatoseAlpha]

I'm assuming he means a readonly variable, not a readonly property.


The literals won't disappear, period. But the variable post-concatenated string can be disposed of when it goes out of scope. As a result, the readonly variable is using up the memory for the string literal, the environment variable, and the concatenation of the two at all times. The shared function creates the concatenation on demand, and it will be destroyed when it goes out of scope.

The practical upshot is that method one stores two strings, plus code, and has to re-concatenate whenever it is called, but the concatenation itself can be disposed of when it's not in use. The latter stores three strings, but does not have to reprocess every time.


String concatenations aren't especially inexpensive operations, and it sounds like it is called multiple times. So unless you're in desperate need of as small a memory footprint as possible, I'd use the readonly variable method simply because concatenating an unchanging string multiple times is wasteful of cpu cycles, and I'm hard pressed to believe the memory usage will be relevant.


Though, to be perfectly blunt, the GUI of the form itself will use so much more memory and cpu cycles then either method, that you'll be hard pressed to notice any actual difference between the two unless your path is a hundred thousand characters or you're calling the function fifty times a second.

 

[WannaFly]

Thanks everyone, it's sounds a bit over my head, but you all bring up good points.

degibson:
what you say about instruction memory makes a lot of sense.

Phatos: I know te GUI willtake much more CPU/memory - and I'm not really trying to make the smallest footprint, but was just curious if there was anything I missed in regards to why I should or shouldnt do it one way or another.

Thanks again everyone for the input!

 

[degibson]

degibson:
what you say about instruction memory makes a lot of sense.

Meh... not so much really. Code and data are allocated at coarse granularity. Its fairly unlikely that either your string literals or your code to manipulate them will increase your static either code or data size. Based on the context, you're obviously unconcerned about performance... so dynamic size doesn't matter much either.

I don't even know for sure if C# code ends up in a code segment or in an interpreter's data segment.

 

[TomGriffinII]

If they are global variables or some such stuff could you not make a resource Satellite DLL (used for software in multiple languages for all the global text/numbers what not)?