String Init

[Alvin Bruney [MVP]]

Sometime ago, i posted a concern about initializing string variables to null
v string.empty. I can't find the thread to reply to it so excuse this one.

I just now thought of this. Isn't it dangerous to initialize variables to
null in a garbage collected environment since garbage collection is
non-dert...yada yada yada.

Consider this, i have a routine spanning 200 lines of code. at the top of
the routine i intialize an object to null. I intend to use this variable at
line 160 for example. At line 10, a garbage collection occurs. Is my code at
line 160 safe, the object is eligible for garbage collection because it has
no roots? This is theoretical and not apt to occur frequently but, right
now, i'm thinking this is terrible if it can actually occur. (haven't given
it much thought just yet)

wouldn't it be best to intialize an object to a root like empty which would
prevent this situation from occuring?

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

[Jon Skeet [C# MVP]]

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

Sometime ago, i posted a concern about initializing string variables to null
v string.empty. I can't find the thread to reply to it so excuse this one.

I just now thought of this. Isn't it dangerous to initialize variables to
null in a garbage collected environment since garbage collection is
non-dert...yada yada yada.

Consider this, i have a routine spanning 200 lines of code. at the top of
the routine i intialize an object to null. I intend to use this variable at
line 160 for example. At line 10, a garbage collection occurs. Is my code at
line 160 safe, the object is eligible for garbage collection because it has
no roots?
What object? There *is* no object, because you've set the variable to
null. Don't forget: the value of a reference-type variable isn't an
object, it's a reference. A reference is either a way of identifying an
object, or null.
This is theoretical and not apt to occur frequently but, right
now, i'm thinking this is terrible if it can actually occur. (haven't given
it much thought just yet)

wouldn't it be best to intialize an object to a root like empty which would
prevent this situation from occuring?

No - because then you're probably creating an object for no reason.
(Not in the case of String.Empty, but in other cases.)

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

[Alvin Bruney [MVP]]

> No - because then you're probably creating an object for no reason.

(Not in the case of String.Empty, but in other cases.)
well that is grasping to me. i will think about creating a small example
which should demonstrate that this may be a problem. Something real world,
aside from the obvious string example.

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

Sometime ago, i posted a concern about initializing string variables to null v string.empty. I can't find the thread to reply to it so excuse this one.
I just now thought of this. Isn't it dangerous to initialize variables to null in a garbage collected environment since garbage collection is
non-dert...yada yada yada.

Consider this, i have a routine spanning 200 lines of code. at the top of the routine i intialize an object to null. I intend to use this variable at line 160 for example. At line 10, a garbage collection occurs. Is my code at line 160 safe, the object is eligible for garbage collection because it has no roots?

What object? There *is* no object, because you've set the variable to
null. Don't forget: the value of a reference-type variable isn't an
object, it's a reference. A reference is either a way of identifying an
object, or null.

This is theoretical and not apt to occur frequently but, right
now, i'm thinking this is terrible if it can actually occur. (haven't given it much thought just yet)

wouldn't it be best to intialize an object to a root like empty which would prevent this situation from occuring?

No - because then you're probably creating an object for no reason.
(Not in the case of String.Empty, but in other cases.)

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

[Alvin Bruney [MVP]]

//managed c++public class Proof {
private int _value;

public Proof ( int v ) { _value = v; }

public static implicit operator int ( Proof c ) {
return c._value;
}
public static explicit operator double ( Proof c ) {
return (double)c._value;
}
}
//new objectProof* c = new Proof(15);//share allocation
int* c1 = *c;[snip]
*c = null;[garbage collection fires off right here]c1 = new Proof(20);Your
explanation for c1 at this point?
-- Regards,Alvin Bruney [ASP.NET MVP]Got tidbits? Get it
here...http://tinyurl.com/3he3b"Alvin Bruney [MVP]" <vapor at steaming post
office> wrote in message news:uI**************@TK2MSFTNGP11.phx.gbl...

No - because then you're probably creating an object for no reason.
(Not in the case of String.Empty, but in other cases.)
well that is grasping to me. i will think about creating a small example
which should demonstrate that this may be a problem. Something real world,
aside from the obvious string example.

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

Sometime ago, i posted a concern about initializing string variables

to null v string.empty. I can't find the thread to reply to it so excuse this one.
I just now thought of this. Isn't it dangerous to initialize variables to null in a garbage collected environment since garbage collection is
non-dert...yada yada yada.

Consider this, i have a routine spanning 200 lines of code. at the top of the routine i intialize an object to null. I intend to use this

variable

at line 160 for example. At line 10, a garbage collection occurs. Is my code at line 160 safe, the object is eligible for garbage collection because

it

has no roots?

What object? There *is* no object, because you've set the variable to
null. Don't forget: the value of a reference-type variable isn't an
object, it's a reference. A reference is either a way of identifying an
object, or null.

This is theoretical and not apt to occur frequently but, right
now, i'm thinking this is terrible if it can actually occur. (haven't given it much thought just yet)

wouldn't it be best to intialize an object to a root like empty which would prevent this situation from occuring?

No - because then you're probably creating an object for no reason.
(Not in the case of String.Empty, but in other cases.)

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

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

No - because then you're probably creating an object for no reason.
(Not in the case of String.Empty, but in other cases.)

well that is grasping to me. i will think about creating a small
example which should demonstrate that this may be a problem. Something
real world, aside from the obvious string example.
In what way is it grasping? If you're not going to use an object,
there's no point in creating it. Setting the value of a variable to
null has no unwanted side-effects as far as I can see. (Setting it to a
reference to an "empty" object has the side-effect of requiring that
object, and the other one previously talked about of coding mistakes
not being spotted where they would throw a (justified) exception
otherwise.)
//managed c++public class Proof {
private int _value;

public Proof ( int v ) { _value = v; }

public static implicit operator int ( Proof c ) {
return c._value;
}
public static explicit operator double ( Proof c ) {
return (double)c._value;
}
}
//new objectProof* c = new Proof(15);//share allocation
int* c1 = *c;[snip]
*c = null;[garbage collection fires off right here]c1 = new Proof(20);Your
explanation for c1 at this point?

Could you give a C# example rather than a C++ example? I don't know the
semantics of MC++ well enough to comment, really. You also need to
explain what you believe the problem shown by your example is - why is
it showing a bad thing?

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

[Alvin Bruney [MVP]]

i'm going to drop this one. i don't think i have arguments that can hold up
in court to support this.

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

No - because then you're probably creating an object for no reason.
(Not in the case of String.Empty, but in other cases.)

well that is grasping to me. i will think about creating a small
example which should demonstrate that this may be a problem. Something
real world, aside from the obvious string example.

In what way is it grasping? If you're not going to use an object,
there's no point in creating it. Setting the value of a variable to
null has no unwanted side-effects as far as I can see. (Setting it to a
reference to an "empty" object has the side-effect of requiring that
object, and the other one previously talked about of coding mistakes
not being spotted where they would throw a (justified) exception
otherwise.)

//managed c++public class Proof {
private int _value;

public Proof ( int v ) { _value = v; }

public static implicit operator int ( Proof c ) {
return c._value;
}
public static explicit operator double ( Proof c ) {
return (double)c._value;
}
}
//new objectProof* c = new Proof(15);//share allocation
int* c1 = *c;[snip]
*c = null;[garbage collection fires off right here]c1 = new

Proof(20);Your explanation for c1 at this point?

Could you give a C# example rather than a C++ example? I don't know the
semantics of MC++ well enough to comment, really. You also need to
explain what you believe the problem shown by your example is - why is
it showing a bad thing?

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

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:

i'm going to drop this one. i don't think i have arguments that can hold up
in court to support this.

There's no need for them to hold up in court for them to be interesting
- whether they're right or wrong, you may well find it helpful to talk
them through anyway, and I'm more than happy to oblige.

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

[Stu Smith]

I know this doesn't address your main concern, but if you're not going to
use your variable until line 160, why not leave declaring it until line 159?
ie;

instead of:

void Foo()
{
Bar bar = null;

// 150 lines of stuff

bar = new Bar();

// etc
}

just do:

void Foo()
{
// 150 lines of stuff

Bar bar = new Bar();

// etc
}

I know we used to have to do it in C but there's no need in C#.
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:uM*************@tk2msftngp13.phx.gbl...

Sometime ago, i posted a concern about initializing string variables to null v string.empty. I can't find the thread to reply to it so excuse this one.

I just now thought of this. Isn't it dangerous to initialize variables to
null in a garbage collected environment since garbage collection is
non-dert...yada yada yada.

Consider this, i have a routine spanning 200 lines of code. at the top of
the routine i intialize an object to null. I intend to use this variable at line 160 for example. At line 10, a garbage collection occurs. Is my code at line 160 safe, the object is eligible for garbage collection because it has no roots? This is theoretical and not apt to occur frequently but, right
now, i'm thinking this is terrible if it can actually occur. (haven't given it much thought just yet)

wouldn't it be best to intialize an object to a root like empty which would prevent this situation from occuring?

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

[Alvin Bruney [MVP]]

agreed

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Stu Smith" <st*****@remove.digita.com> wrote in message
news:ep**************@TK2MSFTNGP10.phx.gbl...

I know this doesn't address your main concern, but if you're not going to
use your variable until line 160, why not leave declaring it until line 159? ie;

instead of:

void Foo()
{
Bar bar = null;

// 150 lines of stuff

bar = new Bar();

// etc
}

just do:

void Foo()
{
// 150 lines of stuff

Bar bar = new Bar();

// etc
}

I know we used to have to do it in C but there's no need in C#.
"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:uM*************@tk2msftngp13.phx.gbl...

Sometime ago, i posted a concern about initializing string variables to null

v string.empty. I can't find the thread to reply to it so excuse this one.
I just now thought of this. Isn't it dangerous to initialize variables to null in a garbage collected environment since garbage collection is
non-dert...yada yada yada.

Consider this, i have a routine spanning 200 lines of code. at the top of the routine i intialize an object to null. I intend to use this variable

at

line 160 for example. At line 10, a garbage collection occurs. Is my

code at

line 160 safe, the object is eligible for garbage collection because it

has

no roots? This is theoretical and not apt to occur frequently but, right
now, i'm thinking this is terrible if it can actually occur. (haven't

given

it much thought just yet)

wouldn't it be best to intialize an object to a root like empty which

would

prevent this situation from occuring?

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b