Menu
Is there any penalty, such that you should only set them as nullable when you really need it?
Thanks
769
You typically use a nullable value type when you need to represent the undefined value of an underlying value type. For example, a Boolean, or bool , variable can only be either true or false . However, in some applications a variable value can be undefined or missing.
Nullable variables may either contain a valid value or they may not — in the latter case they are considered to be nil . Non-nullable variables must always contain a value and cannot be nil . In Oxygene (as in C# and Java), the default nullability of a variable is determined by its type.
In many cases in fact, objects have reference types, can contain a null value, and thus are all nullable; none of these have a Nullable type.
C# - Nullable Types. As you know, a value type cannot be assigned a null value. For example, int i = null will give you a compile time error. C# 2.0 introduced nullable types that allow you to assign null to value type variables.
Various reasons:
Nullable<T> didn't exist until .NET 2.0, and it can't break existing code - especially with the different boxing rules for Nullable<T>
int, I might not want it to be nullable... I want it to be an int, and I don't want to have to check-for/handle nullsbyte[], and now consider if byte was nullable - lots of extra overhead; *plus it would stop you doing blits etc*Performance: Nullable<T> adds lots of extra penalties; in particular lots of hidden calls to .HasValue and .Value / .GetValueOrDefault(); this is shown in particular in the "lifted operators" - i.e. x + y becomes something like below, which adds up for tight loops etc:
(x.HasValue && y.HasValue) ? (x.GetValueOrDefault() + y.GetValueOrDefault()) : null
Likewise, x == y has to check:
== on GetValueOrDefault() of eachlots of overhead....
84
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
