views:

47

answers:

3

Say I were to have a few readonly variables for filepaths, would I be able to guarantee the order in which the values are assigned based on the order of declaration?

e.g.

static readonly string basepath = @"my\base\directory\location";
static readonly string subpath1 = Path.Combine(basepath, @"abc\def");
static readonly string subpath2 = Path.Combine(basepath, @"ghi\klm";

Is this a safe approach or is it possible that basepath may still be the default value for a string at the time subpath1 and subpath2 make a reference to the string?

I realize I could probably guarantee the order by assigning the values in a constructor instead of at the time of declaration. However, I believe this approach wouldn't be possible if I needed to declare the variables inside of a static class (e.g. Program.cs for a console application, which has a static void Main() procedure instead of a constructor).

UPDATE:

I've added the static keyword (as that is what I am using and why it compiles) and also Path.Combine as suggested.

A: 

"is it possible.."

No, the compiler won't let you access basepath from the subpath1/2 declarations. You could do it with constants instead of read-only variables.

kekekela
By saying the compiler won't let me are you saying the code won't compile? It does compile for me.
Jason Down
Just tried it out, I get "A field initializer cannot reference the non-static field, method, or property...".
kekekela
I see. It turns out in this case that these are actually static readonly strings I'm using, so that explains it why I'm getting a different result than you.
Jason Down
Love getting down-voted for being the first to answer with the same info that is in the latter entries. This system baffles me.
kekekela
"It turns out in this case that these are actually static readonly strings I'm using" -- Yeah, that would change things. You didn't have static in the snippet that you posted so...
kekekela
Ya that was my bad. I gave you +1 to cancel out whoever gave you the -1. It does make a difference, so your answer wasn't incorrect for the original question.
Jason Down
Gracias. I would like to downvote their downvote.
kekekela
A: 

I suspect you actually want to use constants:

    const string basepath = @"my\base\directory\location";
    const string subpath1 = basepath + @"\abc\def";
    const string subpath2 = basepath + @"\ghi\klm";

subpath1/2 will definitely have the filled in basepath prefix irrespective of declaration order in the code.

Daniel Renshaw
I'm always torn on constants vs readonly. I've read many things that say not to use constants if there is any chance they will change. These paths might become part of an assembly that other code relies on. I'd want to be able to change these paths without having to recompile the rest of the assemblies that rely on the values of these paths. With constants I would have no choice but to recompile everything, rather than just the DLL.
Jason Down
+2  A: 

The order is unimportant. The runtime guarantees that all objects are initialized when they are used.

Your concrete case is actually not compilable because this could not be guaranteed.

And you are right about the constructor approach. And if you need this for static variables it's no problem either because you can specify a static constructor.

And btw: The correct way of concatenating directories is to use Path.Combine and not string concatenation.

Foxfire
I forgot about the Path.Combine method. Thanks for the reminder.
Jason Down