John Basedow

how can i do this

Nullable<string> s = null;




Re: Visual C# Language nullable on non value types

Tom Meschter MSFT

You don't need to:

string s = null;

should work just fine.

-Tom Meschter

Software Dev, C# IDE






Re: Visual C# Language nullable on non value types

Peter Ritchie

Some more detail... String is not a value type, it's a reference type, so you can use null.




Re: Visual C# Language nullable on non value types

Radha Mukkai

The definition of the Nullable generic structure states:

public struct Nullable<T> where T : struct

As we see, T is constrained to struct (ie., value types). Hence, we cannot "say" Nullable<string> as string is a reference type.





Re: Visual C# Language nullable on non value types

MattDoc

Hi,

Deviating slightly, I heard from a developer I used to work with that 'string' starts life as a value type, and calling methods on it (and presumably setting it to null) causes boxing in the underlying IL, losing a little performance each time this is done.

I was hoping that nullable would work with strings for this reason. Is there any truth to this Has this been improved upon in subsequent versions of C#

Thanks,

Matt





Re: Visual C# Language nullable on non value types

Peter Ritchie

MattDoc wrote:

Hi,

Deviating slightly, I heard from a developer I used to work with that 'string' starts life as a value type, and calling methods on it (and presumably setting it to null) causes boxing in the underlying IL, losing a little performance each time this is done.

I was hoping that nullable would work with strings for this reason. Is there any truth to this Has this been improved upon in subsequent versions of C#

Thanks,

Matt

Sounds more like String's inherent immutability. For example, if you want to modify a string with one of the String methods, you must reassign the result to the original variable (or some variable).

Code Snippet

String text = "some bad text";

text.Replace(" bad", "");

...text doesn't change; and the call to Replace is somewhat redudant. You'd have to do the following:

Code Snippet

String text = "some bad text";

text = text.Replace(" bad", "");

In which case you've thrown away the first string and allocated a new one, possibly leaving "some bad text" in the list of interned strings and possibly added "some text" to the list of interned strings.






Re: Visual C# Language nullable on non value types

MattDoc

Hi,

I'm understand the immutable nature of strings but I think I'm talking about something different.

From what I've heard, when defining a string, it starts off life as a ValueType. Method calls or setting to null cause boxing, so:

string myString = "a string"; // a value type

myString = "another string"; // still a value type

myString.AMethodCall(); // boxed into a reference type

would become something like

.locals init ([0] string myString)

ldstr "a string"

stloc.0

ldstr "another string"

stloc.0

ldloc.0

box [mscorlib]System.String; // <-- performance hit

callvirt instance void [mscorlib]System.String::AMethodCall()

Then, if assigning null values to a string something similar occurs.

string myString = "a string"; // a value type

string myString = null; // boxed into a reference type

If this is the case then surely the nullable structure would cause no boxing. A "string " data type would outperform the standard C# string in database applications (where null values are common) since it remains a value type even when null and no boxing occurs.

--Matt





Re: Visual C# Language nullable on non value types

Peter Ritchie

MattDoc wrote:

Hi,

I'm understand the immutable nature of strings but I think I'm talking about something different.

From what I've heard, when defining a string, it starts off life as a ValueType. Method calls or setting to null cause boxing, so:

string myString = "a string"; // a value type

myString = "another string"; // still a value type

myString.AMethodCall(); // boxed into a reference type

would become something like

.locals init ([0] string myString)

ldstr "a string"

stloc.0

ldstr "another string"

stloc.0

ldloc.0

box [mscorlib]System.String; // <-- performance hit

callvirt instance void [mscorlib]System.String::AMethodCall()

Then, if assigning null values to a string something similar occurs.

string myString = "a string"; // a value type

string myString = null; // boxed into a reference type

If this is the case then surely the nullable structure would cause no boxing. A "string " data type would outperform the standard C# string in database applications (where null values are common) since it remains a value type even when null and no boxing occurs.

--Matt

Nope, string is always a reference type. For your sample code this is the actual IL that is generated (replacing AMethodCall with a real methodl like ToLower):

Code Snippet

L_0000: nop
L_0001: ldstr "a string"
L_0006: stloc.0
L_0007: ldstr "another string"
L_000c: stloc.0
L_000d: ldloc.0
L_000e: callvirt instance string [mscorlib]System.String::ToLower()
L_0013: pop
L_0014: ret

... no boxing.






Re: Visual C# Language nullable on non value types

MattDoc

Thanks, that clears it up.

So the idea of using an proper-case System.String instead of the string keyword for the same performance reasons is out of the window as well. I'm pleased about that and might listen to my colleagues advice with a touch more derision in future.

Cheers Smile

Matt





Re: Visual C# Language nullable on non value types

Peter Ritchie

MattDoc wrote:

Thanks, that clears it up.

So the idea of using an proper-case System.String instead of the string keyword for the same performance reasons is out of the window as well. I'm pleased about that and might listen to my colleagues advice with a touch more derision in future.

Cheers

Matt

Indeed, if they're telling you String/string is a value type, I would definitely question their advice. "string" is just an alias for "System.String", so you don't need a "using System;" to use "string"; whereas using "String" would require the using...