Nullable types in C#
Nullable Types in C#
One of the "late breaking" features in C# 2.0 is what is known as "Nullable Types". The details can be found in the C# 2.0 language spec.
Nullable types address the scenario where you want to be able to have a primitive type with a null (or unknown) value. This is common in database scenarios, but is also useful in other situations.
In the past, there were several ways of doing this:
- A boxed value type. This is not strongly-typed at compile-time, and involves doing a heap allocation for every type.
- A class wrapper for the value type. This is strongly-typed, but still involves a heap allocation, and the you have to write the wrapper.
- A struct wrapper that supports the concept of nullability. This is a good solution, but you have to write it yourself.
To make this easier, in VS 2005, we're introducing a new type named "Nullable", that looks something like this (it's actually more complex than this, but I want to keep the example simple):
struct Nullable<T>
{
public bool HasValue;
public T Value;
}
You can use this struct directly, but we've also added some shortcut syntax to make the resulting code much cleaner. The first is the introduction of a new syntax for declaring a nullable type. Rather than typing:
Nullable<int> x = new Nullable<int>(125);
I can write:
int? x = 125;
which is much simpler. Similarly, rather than needed to write a null test as:
if (x.HasValue) {...}
you can use a familiar comparison to null:
if (x != null) {...}
Finally, we have support to make writing expressions easier. If I wanted to add two nullable ints together and preserve null values, if I didn't have language support, I would need to write:
Nullable<int> x = new Nullable<int>(125);
Nullable<int> y = new Nullable<int>(33);
Nullable<int> z = (x.HasValue && y.HasValue) ?
new Nullable<int>(x.Value + y.Value) : Nullable<int>.NullValue;
At least I think that's what I'd have to write - it's complex enough that I'm not sure this code works. This is ugly enough that it makes using Nullable without compiler support a whole lot of work. With the compiler support, you write:
int? x = 125;
int? y = 33;
int? z = x + y;
Comments
Anonymous
May 27, 2004
What was the reasoning for making the '+' return null instead of throwing an exception when a null value is added to a non-null value?Anonymous
May 27, 2004
This is probably pretty obvious but I'm not seeing the answer.
So is a nullable type a different type or an attribute of a type? Is the following syntax valid?
int x = 0;
int? y = 5;
int z = x + y;
Can nullable types be boxed into non-nullable types IF they have a value?Anonymous
May 27, 2004
I don't mean attribute of a type, I mean inherited from a type. Is a nullable type a child type?Anonymous
May 27, 2004
> Nullable<int> z = (x.HasValue && y.HasValue) ? new Nullable<int>(x.Value + y.Value) : Nullable<int>.NullValue;
Surely you wouldn't have to write that. For example the framework already has a nullable integer SqlInt32, and I hope its arithmetical operators do null propogation for you.
How does boxing work with nullable values, it seems there may be some ambiguity e.g.
int? myValue = null;
DoSomething(myValue)
...
void MyValue(object myObject)
{
// Would this test return true if myObject
// contained a boxed nullable integer whose
// value is null?
if (myObject == null) ...
}Anonymous
May 27, 2004
Are there any issues with adding a dependency on a Framework feature into the compiler/language?
I often wondered about this, specifically with the foreach syntax and IEnumerable.
It just seems odd to me. Though I love the functionality.Anonymous
May 27, 2004
Never mind, I just read the spec. :)Anonymous
May 27, 2004
This sounds like a really great usability enhancement. One quibble though, I find:
Nullable<int> x = 125;
much more obvious and not that much more typing than:
int? x = 125;
Somehow "int?" just looks pretty alien to me. BTW, I am glad you guys came around to the default(T) way of thinking. :-)Anonymous
May 27, 2004
The comment has been removedAnonymous
May 27, 2004
Giampiero: This is convenient because SQL behaves the same way. That is, any mathematical expression with a null value in it, returns null.Anonymous
May 27, 2004
"Somehow "int?" just looks pretty alien to me."
Yeah, like you're not sure of the type or if you want an int. :) Maybe it just stands for "Does it have a value?"Anonymous
May 27, 2004
is
Nullable<int> x = 125;
valid?Anonymous
May 27, 2004
That's seriously cool. Not as cool as Perl 6, of course, but at least there's a vague chance it'll be implemented in my lifetime...Anonymous
May 27, 2004
very cool - nullable types will be very useful..
What would be a whole lot MORE useful [request!!] - non-nullable types.
that is, maybe a keyword notnull or something that checks at the compiler level.
For example:
// generates a compile error
static notnull MyClass x;
// is fine
static notnull MyClass x = new MyClass()
// This class fails to compile, with "X" wasn't initialized
public class blah
{
MyClass notnull x;
blah() {}
}
// this class compiles fine
public class blah2
{
MyClass notnull x;
blah2() {x=new MyClass();}
}
// generates compile error
private void DoSomething()
{ MyClass notnull x;}
// works fine
private void DoSomethingElse()
{ MyClass notnull x = new MyClass();}
// now imagine we have this function
public void DoSomethingWith( MyClass notnull thevariable )
{Debug.Print( thevariable.ToString();}
// works - because new always returns a notnull type!
DoSomethingWith( new MyClass() )
// doesn't work
MyClass y = new MyClass();
DoSomethingWith( y );
// works
MyClass notnull z = new MyClass();
DoSomethingWith( z );
// works
MyClass notnull a = new MyClass();
MyClass b = a;
// doesn't work
MyClass c = new MyClass();
MyClass notnull d = c;
// works
MyClass e = new MyClass();
MyClass notnull f = (MyClass notnull) e;
// or
MyClass notnull f = e as MyClass notnull;
Now, obviously, I could get most of this functionality by defining a template notnull<t>... but then I would only get runtime checking - there is no reason why this shouldn't be done at compile time. (and then once it was in, I'd be arguing that the default should be notnull, and we should be explicitly specifying those few variables which we actually WANT nullable :))
The main thing is, it should be almost trivial to implement from the compiler standpoint, and would provide a quantum leap in program robustness [well, for us, program readability as our code standards ensure that every single public function, constructor, or property setter check each variable is not null - our code would halve in size! :)]Anonymous
May 27, 2004
I really love the propagation of null values. For those who know the functional language Haskell (http://haskell.org): it's very much like the monadic use of the Maybe data type.
<code>
data Maybe a = Nothing | Just a
instance Monad Maybe where ...
-- plain addition
add
:: Maybe Int -> Maybe Int -> Maybe Int
add x y
= case x of
Nothing -> Nothing
Just m -> case y of
Nothing -> Nothing
Just n -> Just (n + m)
-- monadic addition
add' :: Maybe Int -> Maybe Int -> Maybe Int
add' x y = do m <- x ; n <- y ; return (m + n)
</code>Anonymous
May 27, 2004
The comment has been removedAnonymous
May 27, 2004
int? looks like something taken from languages which accepts about anything in a name, and where boolean functions by convention is named like isThisValueANull?(value).
So int? looks like it's asking wether something is an int or not.
I agree that nullable int looks so much better. You love keywords in C#, so why didn't you think of it?
But I wonder most about why I need this? I can't see I have any problems which will be solved by using nullables. In fact, I think I will avoid them as the syntax confuses me. Not very C#-ish.Anonymous
May 27, 2004
Are there already any guidelines how to use this with the two primitive types that already inherently provide a similar feature, albeit in a completely different way? I am talking about Double and Single, which support NaN values, which can also be interpreted as 'value unknown', but without the 'nullable' overhead.
I can imagine that a designer designing a new system that intensively uses floating point numbers, and having the need to represent 'value is missing' somehow, now has two implementation options. And it may not be clear whether a 'nullable' or 'NaN' based approach is best. There will be obvious cases where one or another will be better, but did someone contemplate the effects of choosing one option over another already?
Btw, I did not have time yet to read the spec carefully, if the answer is there, please tell me.Anonymous
May 27, 2004
I think this paper from MSR can explain quite a bit on the choise of syntax for nullable types.
It's just a special case of a more general scheme, where
int? is 0 or 1 int,
int+ is one or more ints,
int* is zero or more ints
int! is exactly one int.
Take a look at the whole paper at
http://research.microsoft.com/~emeijer/Papers/XS.pdfAnonymous
May 27, 2004
Another feature that makes it easier to mess things up (along with anonymous methods). Bad, bad, bad.Anonymous
May 28, 2004
The comment has been removedAnonymous
May 28, 2004
We've heard a lot of positive feedback on the Nullable types. Just so everyone's aware, this is NOT a C# specific feature. VB 2005 has Nullable types and all other generics as well. See the VB Blog at: http://blogs.msdn.com/vbteam/Anonymous
May 28, 2004
OK, after skimming the MS Research paper, I see there is a lot more going on with these special operators (int?/+//!) than I realized. I'm not sure I fully grasp the implications or possibilites yet but it does look interesting. Although I will say that for ex-C/C++ programmers, int has a much different meaning than what is intended with this new feature in C#.Anonymous
May 28, 2004
The comment has been removedAnonymous
May 29, 2004
'Darren Oakey : non-nullable types'
Darren, the Nice language provides separate non-nullable and nullable (heap allocated) types.
See http://nice.sourceforge.net/manual.html#id2494680Anonymous
May 29, 2004
that's very cool - where's Nice for .Net? :) Actually, if you look, the .net team has just added almost all of the functional features to C# too - put together iterators, anonymous methods, generics, you almost have a functional language - which is a very good thing..
Anyway, since writing the request above, I realised you could step a bit of the way with templates. I did it for a few days, and it was a bit annoying in it's syntax, so I relaxed the rules a bit, and dropped down from compiler time checking to runtime checking, but I love it - I can now say
NonNull<Employer> FindEmployer( NonNull<string> EmployerName )
{
...
}
and be able to propagate those non-nulls through - so I reduce the checking I have to do, and guarantee that everything is checked...
However it's not as pretty as I would like, and not compiler time checked - a very simple change to the language would allow that.
Here's the code if anyone wants it:
/// <summary>
/// This class specifies that we are using a non-null version of the type
/// </summary>
/// <typeparam name="TheType">the type we are wrapping</typeparam>
public class NonNull<TheType>
{
/// <summary>
/// the value we are wrapping
/// </summary>
private TheType _value;
/// <summary>
/// Construct this with thsi value
/// </summary>
/// <param name="value">the value to construct with</param>
public NonNull( TheType value )
{
if (value == null)
throw new ArgumentNullException("value", "an attempt was made to construct a non-null value from a null");
_value = value;
}
/// <summary>
/// Convert this to a string - we just pass this off to the value we are wrapping,
/// who we know is not null :)
/// </summary>
/// <returns>the value to string</returns>
public override string ToString()
{
return _value.ToString();
}
/// <summary>
/// this is a bit of a kludge, but allows us to call methods on the base type.. ideally the
/// compiler would support this directly!!!
/// eg myVar.Call.MyFunction
/// </summary>
/// <value></value>
public TheType Call
{
get { return _value; }
}
/// <summary>
/// we make sure that our non-null version of the type can always be used just as the type
/// itself would be, by making an implicit casting operator
/// </summary>
/// <param name="theValue">the non-null value</param>
/// <remarks>it is important to remember that we have SPECIFICALLY NOT created an implicit
/// operator the other way around - it would be easy to do, and would still give us runtime
/// checking, but we always want to make sure the developer is thinking, when they go from
/// nullable to non-null... so DON'T ADD IT!!</remarks>
/// <returns>the original value</returns>
public static implicit operator TheType(NonNull<TheType> theValue)
{
return theValue._value;
}
/// <summary>
/// This shouldn't exist, but the code was a nightmare otherwise - guess I'll have to live
/// with runtime checking only, instead of compile time
/// </summary>
/// <param name="value">the value to add</param>
/// <returns>the value</returns>
public static implicit operator NonNull<TheType>(TheType value)
{
return new NonNull<TheType>(value);
}
}
have fun with it!Anonymous
May 29, 2004
The comment has been removedAnonymous
May 30, 2004
While I can only approve the introduction of generics and iterators in C#, two things that are necessary and useful, I must say that I have serious doubts about anonymous methods and nullable types.
The one thing I liked about C# as it emerged, was its relative simplicity. Many keywords (too many, some say), and yet a few relatively simple concepts. I've always placed C# between C++ and Java, with the full arsenal of C++, but without the monstruos constructs backwards compatibility imposed on C++ and the clumsy interpretation of "everything is an object" in Java.
This doesn't mean that I don't approve the introduction of these features. However, with the multi-language support the .NET platform has, I would have expected new languages or new class libraries instead of new features to existing languages. Off topic, I think the C++ tweaks Microsoft is working on are already pushing the limits too far (in the wrong direction). Not to mention VB, but that's a different story. Anyway, regarding C#, "if it works, don't fix it", right?
I can only hope the design team has considered all implications and that the new features will follow the principle "pay as you go" - developers not using the new features should not be subjected to performance or other kinds of penalties. I guess that won't be true for the runtime, anyway.
Of course, perhaps I just don't share your view on these things, so my opinion might be irrelevant after all :) I'm only curious how many of the developers using C# out there actually requested or approved this particular feature.
PS:
int? x = 125;
int? y = 33;
int? z = x + y;
doesn't work in the March preview release of Whidbey. "Operator '+' cannot be applied to operands of type 'System.Nullable<int>' and 'System.Nullable<int>'". Will it work in the release version? If not, then the 'int?' stuff might be just useless syntactic sugar over a framework construct :(Anonymous
May 31, 2004
Darren: "the .net team has just added almost all of the functional features to C#"
Not really ;-)
Look at Nemerle or F# or SML.Net and you'll soon see the difference.Anonymous
May 31, 2004
The comment has been removedAnonymous
June 01, 2004
Interesting extensions...Anonymous
June 02, 2004
I must say that C# is a nice language but it misses one of the key things that makes for widespread adoption of it by developers... cross platform compatibility.
The reason why Java became so popular was that you write code once and then use it anywhere. The whole idea behind OOP is that you plan on reusing code. And what good is it if I can only reuse that code on one platform?
Sure. It's great for desktop apps. Fantastic. You have hit your target demographic. But to get web developers to use it when Apache is the most popular web server and to get system administrators or application developers for portable devices to use it is not very likely.
Alot of people point ot MONO (which is still in beta) and say that makes C# cross platform... but no, it doesn't really. The project is getting no support from Microsoft who can at anytime change their spec and make all that code useless.
So why, as a developer, would I ever want to use an OOP language that isn't cross platform?
The only reason I make this whole point is that I spent the last few months making a long decision of what to use... Java or C# for my next project. I researched them both and they both have a similar level of functionality Java is still a bit faster but Microsoft makes up for this by integrating the virtual machine into their OS.
And what it finally came down to was that I plan to be doing web development and portable applications. And when you consider that, Java is the natural choice. My code can go anywhere .
If I was building a desktop application, I'd probably use C instead of C#; I mean after all, if you are going to be building code that works on one platform, stick with the tried and true.Anonymous
June 02, 2004
I just found this...it's MS's plans for nullable primitives implemented in VS 2005http://blogs.msdn.com/ericgu/archive/2004/05/27/143221.aspxAnonymous
June 02, 2004
Also see http://blogs.msdn.com/ericgu/archive/2004/05/27/143221.aspx (MS implementation of Nullable Types scheduled for .NET 2.0).Anonymous
June 02, 2004
Nathan, I was with you up to the part about using C to develop desktop apps. That's so early '90s! Most people either use C++ with MFC or VB6. I personally prefer C# and WinForms.Anonymous
June 02, 2004
Eric Gunnerson blogged last week about Nullable types in C# 2.0. This new C# feature will allow one to specify a Type like int? which will act just like a regular int, with the exception that it can now also be null. The "?" syntax comes from this Microsoft Research paper, which introduces the following Regex-inspired Type-modifiers: Type*Zero or more...Anonymous
June 02, 2004
True. C++ is definitely the BETTER choice. But I HATE the way it handles objects... blech! :)Anonymous
June 03, 2004
???????????? syntax sugar ?? C# 2.0 ???,???? Nullable types in C# ????? ????????? value type ??? null ????? int? x = 125if (x != null) {...} ???????,???????????? -1 ??????????????...Anonymous
June 03, 2004
One confusion I'm seeing is that cardinality is being confused with reference versus value (i.e. heap allocated versus stack allocated). They aren't actually the same thing, but by default a cardinality of 0 or 1 is associated with reference variables and a cardinality of exactly 1 is associated with value types. They don't have to be and in my opinion they shouldn't be.
IMO, by default all objects should have cardinality 0 or 1 (!). So string should be the same as string! and int should be the same as int!.
As a programmer, I shouldn't really care how variables are stored (i.e. stack versus heap). That's really the compiler's problem. But I always care about the structure of my data (i.e. its types and those variable's cardinalities).
Orion AdrianAnonymous
June 03, 2004
Dunno about anyone else, but 'int?' certainly doesn't read as well as 'nullable int'. I can see where they are coming from, but int* already has another well recognized meaning, so using that family of notation may be a bit ambiguous. Then again, just an opinion. Are there any statistics, or polls out there which present the options? It might be a pain to type the 'nullable' keyword, but then again, the 'return' keyword isn't intellisensed either, and that doesn't hurt anyone.Anonymous
June 04, 2004
So can we assume that the next generation of typed DataSets will utilize this feature and do away with the horrible IsFieldNameNull() convention?
Please, please, please?
What happens if I write:
int? i;
int x = i;
Will this throw an error at compile time or a null reference exception? Something else?Anonymous
June 04, 2004
Checking out the code
int? i;
int x = i;
left me wondering what happened to the definite assignment requirement?Anonymous
June 04, 2004
Nothing doing.Anonymous
June 09, 2004
So I checked the following code...
int? i;
int x = i;
This gives a compile error saying an indirect cast is not allowed.
int? i;
int x = (int)i;
This gives a compiler error saying I'm using the uninitialized value, "i"
int? i = null;
int x = (int)i;
This compiles but I get a runtime error. I looked and strongly typed datasets are not using this feature. We are still stuck with "IsFieldNameNull()" methods. :-(
When I compile the following code:
int? i = null;
if ( i == null )
{}
I get a compiler warning saying that (i == null) is obsolete and to replace it with a static method. Is this correct? The code above shows the == operator working.Anonymous
June 10, 2004
The comment has been removedAnonymous
June 11, 2004
One of the features I value most about C# is simplicity. While it is currently a little more complex than I think it should be, adding this type of complexity on something as simple as a null seems a step backward. It will cost more in debugging and code research due to incompatible types along with cluttering up your code with symbols that have meaning on their own beyond this use.
Do not understand why other value types cannot address null as simply as "string" does today. While, I do have a problem with a null string and string.empty(), it would be nice to see int == null and would keep things simple.
Although I see the need for generics in some form, it appears more everyday that C# is stepping backward to become another C++ with garbage collection. Code will become more cryptic and debugging time will increase.
For me it is simplicity, which equates to less development time, easier to maintain and less debugging. You increase any of those, C# suffers along with .NET.Anonymous
June 14, 2004
The comment has been removedAnonymous
June 14, 2004
Nathan: <tedious off-topic rubbish about how C# is unsuitable for anything because it isnt 'cross-platform'>
I guess you just wanted to regurgitate some turgid off-topic received 'wisdom' and this was the blog article that you happened to be browsing when the muse took you. Anyway, thanks for that inconoclastic bombshell of a comment.Anonymous
June 14, 2004
Rocky, the reason the value types can't do this as easily as string is because string is a reference type. So null is a natural, valid state for a reference type. I like the addition of the "simplified" generics which are quite different from C++ templates. The one thing I am not sure I like is the function syntax changes like:
int? i = null;
int j = i ?? 5;
Actually I am getting used to "??" but I still don't like:
int?
Is this an int that can't make up its mind as to whether or not it's actually an int? I just don't like the whole application of regular expressions syntax in a programming language where the vast majority of C# programmers take this:
int*
To mean something entirely different than 0 or more ints.Anonymous
June 17, 2004
I'm really looking forward to this. I don't need nullable types every day, but when I do, I find it pretty annoying to have to work around it. At least in Java there were corresponding wrapper types, so you could do something like:
public void Register(String email, Boolean optIn)
where optIn would be null if the user did not answer the question. I like the idea of this in C#:
public void Register(String email, bool? optIn)
Seems like the best of all worlds to me. If you are afraid of null values, don't use the nullable type. But I say, better to have clearly nullable values than "magic" values (like Stream.ReadByte() returning -1 when the stream is done) which are too easily ignored.Anonymous
June 17, 2004
I like the functionality, it is just the syntax that I'm not sure I like. Is the following that much harder to read:
public void Register(String email, Nullable<bool> optIn)
I don't think so. In fact, I think it is easier to read.Anonymous
June 21, 2004
The comment has been removedAnonymous
July 01, 2004
The comment has been removedAnonymous
July 05, 2004
The comment has been removedAnonymous
July 05, 2004
Hm. Just realised that boxing an int? as null won't work cause then it can't be unboxed.
Hmm...it's a pickle.Anonymous
July 16, 2004
The comment has been removedAnonymous
July 28, 2004
I'd just like to add a +1 on the 'nullable int i' syntax and a -1 on the 'int? i' syntax. Keywords are easier to understand, and not much harder to write. I think the ugly < and > introduced with Generics is enough special syntax to introduce to the language.
The simpler, the better. If C# continues to add new syntactical tokens to the language, it will be more difficult to understand, it will be more difficult to read, and just simply look uglier. We want C# to be beautiful, don't we? At least, I do.Anonymous
December 18, 2004
Helpful For MBA Fans.Anonymous
December 27, 2004
[http://itpeixun.51.net/][http://aissl.51.net/][http://kukuxz003.freewebpage.org/][http://kukuxz001.51.net/][http://kukuxz003.51.net/][http://kukuxz005.51.net/][http://kukuxz002.51.net/][http://kukuxz004.freewebpage.org/][http://kukuxz007.51.net/][http://kukuxz001.freewebpage.org/][http://kukuxz006.51.net/][http://kukuxz002.freewebpage.org/][http://kukuxz004.51.net/][http://kukuxz008.51.net/][http://kukuxz009.51.net/][http://kukuxz005.freewebpage.org/][http://kukuxz006.freewebpage.org/][http://kukuxz007.freewebpage.org/][http://kukuxz009.freewebpage.org/]Anonymous
December 30, 2004
Nullable value typesAnonymous
April 07, 2005
<p>Dare Obasanjo<br/>Microsoft Corporation</p><div id=""><p><b>摘要:</b>Dare Obasanjo 介绍了 C-Omega 编程语言,这种语言是由 Microsoft Research 创建的,方法是增加 C# 的构造,使之能够更好地处理诸如 XML 和关系数Anonymous
April 15, 2005
Ping Back来自:blog.csdn.netAnonymous
April 26, 2005
More info on nulls for Kyle http://davidkean.net/archive/2005/04/25/393.aspx http://blogs.msdn.com/ericgu/archive/2004/05/27/143221.aspx...Anonymous
July 02, 2005
有些情况下,非类型化的 DataSet 可能并非数据操作的最佳解决方案。本指南的目的就是探讨 DataSet 的一种替代解决方案,即:自定义实体与集合。(本文包含一些指向英文站点的链接。)Anonymous
July 05, 2005
XML 专栏:C-Omega 概述发布日期: 4/4/2005 | 更新日期: 4/4/2005Dare ObasanjoMicrosoft Corporation摘要:Dare Obasanjo 介绍了 C-Omega 编程语言,这种语言是由 Microsoft Research 创建的,方法是增加 C# 的构造,使之能够更好地处理诸如 XML 和关系数据等信息。本页内容简介C-Omega 类型系统C-Omega 中的查询运算符在 C-Omega 中使用 XML小结致谢简介XML 异军突起成为信息交换的通用语言,一个主要的原因是其不同于以前的数据交换格式,XML...Anonymous
August 01, 2005
摘要:有些情况下,非类型化的 DataSet 可能并非数据操作的最佳解决方案。本指南的目的就是探讨 DataSet 的一种替代解决方案,即:自定义实体与集合。(本文包含一些指向英文站点的链接。)
...Anonymous
February 07, 2006
We have always enjoyed the ability of setting&nbsp;reference types to&nbsp;null (Nothing in VB)&nbsp;from...Anonymous
February 08, 2006
If you've been programming with databases much, you have probably run into the cAnonymous
March 18, 2006
Reminder to self for when I inevitably loose the bookmarks when my computer goes on a bookmark eating frenzy: -- Nullable Types in C# -- The Truth about Nullable Types and VB... -- Why don't nullable relational operators return bool?...Anonymous
March 21, 2006
掌握 ASP.NET 之路:自定义实体类简介Anonymous
August 14, 2006
掌握 ASP.NET 之路:自定义实体类简介Anonymous
August 16, 2006
The comment has been removedAnonymous
September 29, 2006
Just a couple of links to some useful 2.0 functionality
•
Eric Gunnerson - Nullable Types in...Anonymous
October 17, 2006
Karl Seguin Microsoft Corporation 摘要:有些情况下,非类型化的 DataSet 可能并非数据操作的最佳解决方案。本指南的目的就是探讨 DataSet 的一种替代解决方案,即:自定义实体与集合。(本文包含一些指向英文站点的链接。) http://www.microsoft.com/china/MSDN/library/WebServices/default.mspx?mfr=trueAnonymous
December 25, 2006
发布日期:5/24/2005|更新日期:5/24/2005 KarlSeguinMicrosoftCorporation 摘要:有些情况下,非类型化的DataSet可能并非数据...Anonymous
February 10, 2007
We have always enjoyed the ability of setting reference types to null (Nothing in VB) from the earlyAnonymous
April 12, 2007
本指南的目的就是探讨 DataSet 的一种替代解决方案,即:自定义实体与集合。本指南的目的就是探讨一种适合处理此类工作的 DataSet 的替代解决方案,即:自定义实体与集合。记住,每种解决方案都有优缺点,所以 DataSet 的缺点可能比自定义实体的缺点(我们也将进行讨论)更容易让您接受。最后请注意,我所说的 DataSet 并不是类型化的 DataSet,但它确实可以弥补非类型化的 DataSet 的一些缺点。寻找替代解决方案的第一个也是最明显的原因就是 DataSet 无法从数据库结构中提取代码。这些核心数据库组件也是..Anonymous
June 24, 2007
PingBack from http://learningdotnet.wordpress.com/2007/06/24/chap-1/Anonymous
November 05, 2007
PingBack from http://asbjorn.ulsberg.no/wp/?p=27Anonymous
April 08, 2008
PingBack from http://journal.stuffwithstuff.com/2008/04/08/whats-the-opposite-of-nullable/Anonymous
May 02, 2008
hi3x setelah ampir 2 taun kenal C# baru sekarang gua kenal ama tipe yang satu ini. okeh kronologisnyaAnonymous
May 02, 2008
PingBack from http://codingly.com/2008/05/02/optimisation-des-invocations-dynamiques-de-methodes-en-c/Anonymous
June 06, 2008
Nullable Types in C# One of the "late breaking" features in C# 2.0 is what is known as "Nullable Types". The details can be found in the C# 2.0 language spec . Nullable types address the scenario where you want to be able to have aAnonymous
July 28, 2008
PingBack from http://vkreynin.wordpress.com/2008/07/28/how-big-is-null-in-nullable-types/Anonymous
January 20, 2009
PingBack from http://www.hilpers.com/869927-ungueltige-konvertierung-von-der-zeichenfolge/2Anonymous
May 28, 2009
PingBack from http://paidsurveyshub.info/story.php?title=eric-gunnerson-s-c-compendium-nullable-types-in-cAnonymous
May 31, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=1656Anonymous
May 31, 2009
PingBack from http://woodtvstand.info/story.php?id=2601Anonymous
June 02, 2009
PingBack from http://woodtvstand.info/story.php?id=43789Anonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=7993Anonymous
June 09, 2009
PingBack from http://weakbladder.info/story.php?id=88Anonymous
June 09, 2009
PingBack from http://jointpainreliefs.info/story.php?id=918Anonymous
June 09, 2009
PingBack from http://toenailfungusite.info/story.php?id=3151Anonymous
June 15, 2009
PingBack from http://softwareduesouth.wordpress.com/2009/06/16/nullable-types/Anonymous
June 16, 2009
PingBack from http://fixmycrediteasily.info/story.php?id=2813Anonymous
June 17, 2009
PingBack from http://patiosetsite.info/story.php?id=592