|
Kamarey wrote: >>All data types support null
Are you sure in that?
Positivly.
What about int, float?
int i = 0;
float f = 0.0; If you need some "Out of band" signaling for "not valid", I personally would use a separate bool for valid or not.
Thats what C# is doing behind the curtains with its nullable types anyway.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Exactly what the previous guy said. int?, bool?, decimal?, etc.
ROFLOLMFAO
|
|
|
|
|
Gotta love it when using C#. Although I have to say that it sometimes is unclear what the compiler will put in place.
WM.
What about weapons of mass-construction?
"You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
|
|
|
|
|
null for reference types, and otherwise empty constructor for value types 
|
|
|
|
|
Null and DbNull are two different things, and given that most of what I work with ends up persisting to a database where DbNull has meaning and relevance, I find myself dealing with how a DbNull is represented to the user (not to mention internally). It's a shame that there isn't better coupling between C#'s nullable types and the DB persistence framework. What I'd like to see is more thought put into the entire issue of database, internal, and UI representation of nullable fields and default values and how they are handled. As it is, I have to write code to do all that manually, which is fine, but it seems like it's something that the C# language and .NET framework could address.
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
Yes, I expected the new Nullable type to be able to deal with DbNull but was surprised it couldn't.
Kevin
|
|
|
|
|
it depends on the situation. Sometimes you are using and object instance that doesn't have an "Empty" value so its easier to use null value instead. Also null value may help you find out that the variable has not been used or isn't needed anymore.
|
|
|
|
|
There are many situations where is needed to know if we deal with no value or empty. I mean, sometimes a user has selected empty value for an option, and in this case no default value comes into place. It's not the same case when the same user has made no selection at all, this time, a null value is handy.
|
|
|
|
|
|
Especially with HANDLEs or other handle types (like HKEY), it's nice to have NULL or INVALID_HANDLE_VALUE as a sentinel to indicate that no clean-up is necessary.
|
|
|
|
|
On the other hand, the absence of a handle (as opposed to storing a NULL value), is an information carrier as well. It all depends on what meaning you assign to NULL. If you're caching handles, the absence of a handle could for instance mean that the corresponding socket is not connected, non-NULL values mean live sockets, and NULL values indicate pending socket connections. (This is actually a bad example, as such states should probably be indicated by means of enums - but you get the point).
--
-= Proudly Made on Earth =-
|
|
|
|
|
there may be situations when you want to fake a null value (aka:more than 1 kind of a null value)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
