Instatiating an object in the get property method

[Jack Addington]

Is it bad form to instatiate a private variable in the get method of a
property declaration?

ie)

private objA _someVar;

public objA SomeVar
{
get { if( _someVar == null) _someVar = new objA();
return _someVar;
}
}

[Nicholas Paldino [.NET/C# MVP]]

Jack,

No, this is not a bad idea at all. It's referred to as "lazy-loading"
and is done when the resource is expensive to create.

The only problem with this is that it is not thread safe. If this is
the case, then you will have to use a lock statement (I recommend the double
check lock pattern) to create the instance if it is not created already.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jack Addington" <ja********@shaw.ca> wrote in message
news:OI****************@tk2msftngp13.phx.gbl...

Is it bad form to instatiate a private variable in the get method of a
property declaration?

ie)

private objA _someVar;

public objA SomeVar
{
get { if( _someVar == null) _someVar = new objA();
return _someVar;
}
}

[Ming Chen]

Hi, Jack.
As long as the design is solid, I don't see any systematic problem with
this technic. For example, it could be used to perform a delayed instantiate
a singleton object.

Ming Chen

"Jack Addington" <ja********@shaw.ca> wrote in message
news:OI****************@tk2msftngp13.phx.gbl...

Is it bad form to instatiate a private variable in the get method of a
property declaration?

ie)

private objA _someVar;

public objA SomeVar
{
get { if( _someVar == null) _someVar = new objA();
return _someVar;
}
}

[Jon Skeet [C# MVP]]

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:

No, this is not a bad idea at all. It's referred to as "lazy-loading"
and is done when the resource is expensive to create.

The only problem with this is that it is not thread safe. If this is
the case, then you will have to use a lock statement (I recommend the double
check lock pattern) to create the instance if it is not created already.

The double-check lock pattern doesn't work in .NET unless the variable
is also volatile. There's no guarantee that the object will have
completed being constructed before the value in the variable is set to
the new reference, for example.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Jin <Da*******@discussions.microsoft.com> wrote:

but if you are running the code on a x86 machine, double locking should be
ok, correct? though it could potentially be ported to a system with very
weak memory model.

I don't know whether it's definitely correct, even on x86. It may well
be, but I certainly wouldn't like to write a load of code assuming it.
You never know where your code will end up...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Scott Allen]

On Tue, 21 Sep 2004 18:40:03 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Daniel Jin <Da*******@discussions.microsoft.com> wrote:

but if you are running the code on a x86 machine, double locking should be
ok, correct? though it could potentially be ported to a system with very
weak memory model.

I don't know whether it's definitely correct, even on x86. It may well
be, but I certainly wouldn't like to write a load of code assuming it.
You never know where your code will end up...

CLI I 12.6.8 says:

"It is explicitly not a requirement that a conforming implementation
of the CLI guarantee that all state updates performed within a
constructor be uniformly visible before the constructor completes.
CIL generators may ensure this requirement themselves by inserting
appropriate calls to the memory barrier or volatile write
instructions. "

When I read this it tends to make me want to err on the safe side and
avoid the situation altogether. You never know what conforming
implementation your code might end up on...

--
Scott
http://www.OdeToCode.com

[Daniel Jin]

but if you are running the code on a x86 machine, double locking should be
ok, correct? though it could potentially be ported to a system with very
weak memory model.

"Jon Skeet [C# MVP]" wrote:

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:

No, this is not a bad idea at all. It's referred to as "lazy-loading"
and is done when the resource is expensive to create.

The only problem with this is that it is not thread safe. If this is
the case, then you will have to use a lock statement (I recommend the double
check lock pattern) to create the instance if it is not created already.

The double-check lock pattern doesn't work in .NET unless the variable
is also volatile. There's no guarantee that the object will have
completed being constructed before the value in the variable is set to
the new reference, for example.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too