Fave Operator of the Day
-
You tease - don't blue-ball us, give up an example!!! :)
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
Also easy when working with strings. string result = someString ?? string.Empty;
-
The C# 2.0 null coalescing operator
??God bless its little cotton socks.cheers, Chris Maunder
CodeProject.com : C++ MVP
Aha.. so when is CodeProject being upgrade to 3.5 then ? ;)
'Howard
-
The C# 2.0 null coalescing operator
??God bless its little cotton socks.cheers, Chris Maunder
CodeProject.com : C++ MVP
For the really nerdy:
string value = value1 ?? value2 ?? value3 ?? finalDefaultValue;Deja View - the feeling that you've seen this post before.
-
For the really nerdy:
string value = value1 ?? value2 ?? value3 ?? finalDefaultValue;Deja View - the feeling that you've seen this post before.
OK. For us poor, ignorant C++ jocks, please explain what that abomination does. I'm guessing it's something like this:
if (value1 != NULL) value = value1;
else if (value2 != NULL) value = value2;
else if (value3 != NULL) value = value3;
else value = finalDefaultValue;
Software Zen:
delete this; -
OK. For us poor, ignorant C++ jocks, please explain what that abomination does. I'm guessing it's something like this:
if (value1 != NULL) value = value1;
else if (value2 != NULL) value = value2;
else if (value3 != NULL) value = value3;
else value = finalDefaultValue;
Software Zen:
delete this;Yup - that's exactly what it does - it coalesces through the chain until it finds a none-null value.
Deja View - the feeling that you've seen this post before.
-
Yup - that's exactly what it does - it coalesces through the chain until it finds a none-null value.
Deja View - the feeling that you've seen this post before.
I'm curious. Does this pattern occur often enough in .NET programming that it was worth adding an operator for it? Or is it the case that, since the operator is available, you use that pattern more often?
Software Zen:
delete this; -
I'm curious. Does this pattern occur often enough in .NET programming that it was worth adding an operator for it? Or is it the case that, since the operator is available, you use that pattern more often?
Software Zen:
delete this;I use ?? from time to time, but I needed more than a single ?? in an expression. I think a "?." operator would be much more useful than ??. "obj?.Method()" could be syntax sugar for "(obj != null) ? obj.Method() : null" (except that "obj" is evaluated only once). Hopefully MS will add something like that to C# 4.0...
-
I'm curious. Does this pattern occur often enough in .NET programming that it was worth adding an operator for it? Or is it the case that, since the operator is available, you use that pattern more often?
Software Zen:
delete this;Gary Wheeler wrote:
Does this pattern occur often enough in .NET
In normal code, there is often times you want to get a value back, even if it is a specific default value rather than having to deal with nulls. Now that there is nullable types, it happens quite a bit more. While I am not sure that there is a need for a chain of values as mentioned in the prior post, the ?? is handy to have around.
Rocky <>< Blog Post: LINQ Scores a Yahtzee! Tech Blog Post: Cheap Biofuels and Synthetics coming soon?
-
For the really nerdy:
string value = value1 ?? value2 ?? value3 ?? finalDefaultValue;Deja View - the feeling that you've seen this post before.
Ok, so we comparing nerdiness, beat this one for flavour :)
class Foo
{
CallTargetWithContext0 target0;
CallTargetWithContext1 target1;
CallTargetWithContext2 target2;
CallTargetWithContext3 target3;
CallTargetWithContext4 target4;
CallTargetWithContext5 target5;
CallTargetWithContextN targetN;public Foo(Delegate target)
{
target =
(target0 = target as CallTargetWithContext0) ??
(target1 = target as CallTargetWithContext1) ??
(target2 = target as CallTargetWithContext2) ??
(target3 = target as CallTargetWithContext3) ??
(target4 = target as CallTargetWithContext4) ??
(target5 = target as CallTargetWithContext5) ??
// for some reason the last one needs a cast...
((Delegate)(targetN = target as CallTargetWithContextN));
}
}xacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach." -
The C# 2.0 null coalescing operator
??God bless its little cotton socks.cheers, Chris Maunder
CodeProject.com : C++ MVP
I just had to show someone how to use that yesterday. Also remember it was one of the coding questions of the day here a while back. My favorite operator is noop. I would get it on a tag if I wasn't afraid muggles would mispronounce it.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
yeah, I still from time to time type if (myobj) and then remember.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Discovering that C# does not support that, my happy face turned into a sad face :(
-
Personally, i'd have preferred something along the lines of the GNU C "shortcut ternary" operator (which it closely resembles). But then, i'd have liked it if C# interpreted
nullvalues asfalseinstead of requiring an explicit comparison... :->----
...the wind blows over it and it is gone, and its place remembers it no more...
Frankly, I am getting tired of null reference exceptions. I just wish C#/.NET wouldn't be so finicky about null references. For example the latest issue I had was with a MediaPlayer object, where I close the (possibly) existing player before starting a new one: player.Stop(); player = new MediaPlayer(); ... But if I haven't already created a MediaPlayer I get a freaking null reference exception. Of course I know that I should know better and test player for null, but my point is I don't CARE if player.Stop() fails, it's not going to aversely affect my function at all anyway, and my argument is that I bet in 80-90% of cases, null reference exceptions that slip through in production code probably would work fine if they were simply ignored, like my example above. Who's with me for demanding that null reference exceptions be ignored by default and only thrown in blocks explicitly marked as such! Lol, just a mini-rant. :P
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
-
Ok, so we comparing nerdiness, beat this one for flavour :)
class Foo
{
CallTargetWithContext0 target0;
CallTargetWithContext1 target1;
CallTargetWithContext2 target2;
CallTargetWithContext3 target3;
CallTargetWithContext4 target4;
CallTargetWithContext5 target5;
CallTargetWithContextN targetN;public Foo(Delegate target)
{
target =
(target0 = target as CallTargetWithContext0) ??
(target1 = target as CallTargetWithContext1) ??
(target2 = target as CallTargetWithContext2) ??
(target3 = target as CallTargetWithContext3) ??
(target4 = target as CallTargetWithContext4) ??
(target5 = target as CallTargetWithContext5) ??
// for some reason the last one needs a cast...
((Delegate)(targetN = target as CallTargetWithContextN));
}
}xacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."Oooh - I like that one. The code is completely impenetrable and adds unnecessary complexity. I like it.:-D
Deja View - the feeling that you've seen this post before.
-
The C# 2.0 null coalescing operator
??God bless its little cotton socks.cheers, Chris Maunder
CodeProject.com : C++ MVP
It is up there, but not equal to the nullable int (not an assignment operator like ??, but a little known feature and useful none the less) int? myNullableInt = null; Console.WriteLine(myNullableInt ?? "Null"); myNullableInt = 1; Console.WriteLine(myNullableInt ?? "Null"); Outputs: null 1
-
Jim Crafton wrote:
is there a VB equivalent
Who cares ;)
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
norm .net wrote:
Jim Crafton wrote: is there a VB equivalent Who cares
People in jobs that require the use of VB. >.<
-
Oooh - I like that one. The code is completely impenetrable and adds unnecessary complexity. I like it.:-D
Deja View - the feeling that you've seen this post before.
Pete O`Hanlon wrote:
The code is completely impenetrable and adds unnecessary complexity.
In fact, the code is highly optimized for typesafe assignment. IIRC when I tried to rewrite with if's, the generated IL was a lot more 'verbose'. :)
xacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach." -
Frankly, I am getting tired of null reference exceptions. I just wish C#/.NET wouldn't be so finicky about null references. For example the latest issue I had was with a MediaPlayer object, where I close the (possibly) existing player before starting a new one: player.Stop(); player = new MediaPlayer(); ... But if I haven't already created a MediaPlayer I get a freaking null reference exception. Of course I know that I should know better and test player for null, but my point is I don't CARE if player.Stop() fails, it's not going to aversely affect my function at all anyway, and my argument is that I bet in 80-90% of cases, null reference exceptions that slip through in production code probably would work fine if they were simply ignored, like my example above. Who's with me for demanding that null reference exceptions be ignored by default and only thrown in blocks explicitly marked as such! Lol, just a mini-rant. :P
{o,o}.oO( Did somebody say “mouse”? ) |)””’) -”-”-
logan1337 wrote:
and my argument is that I bet in 80-90% of cases, null reference exceptions that slip through in production code probably would work fine if they were simply ignored, like my example above.
Are you nuts? :~ You're responsible for telling the computer what to do. If you hand it a null reference, your method call can't actually be called. If you didn't need it to be called, you shouldn't have written it! Just think - you could have been trying to do anything. Essentially, you're saying that the runtime should plow through catastrophic bugs and attempt to keep executing something, on the assumption that major portions of your code aren't actually important anyway! No. No, no no. This is the road to unpredictable software, bugs that can never be reliably reproduced or tracked back to their original cause, shoddy software that works once, for the single scenario the developer tests under, but trashes the machines of half the end users. :sigh:
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
It is up there, but not equal to the nullable int (not an assignment operator like ??, but a little known feature and useful none the less) int? myNullableInt = null; Console.WriteLine(myNullableInt ?? "Null"); myNullableInt = 1; Console.WriteLine(myNullableInt ?? "Null"); Outputs: null 1
MrEyes wrote:
Outputs: null
No that would be "Null" :)
xacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach." -
MrEyes wrote:
Outputs: null
No that would be "Null" :)
xacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach." -
logan1337 wrote:
and my argument is that I bet in 80-90% of cases, null reference exceptions that slip through in production code probably would work fine if they were simply ignored, like my example above.
Are you nuts? :~ You're responsible for telling the computer what to do. If you hand it a null reference, your method call can't actually be called. If you didn't need it to be called, you shouldn't have written it! Just think - you could have been trying to do anything. Essentially, you're saying that the runtime should plow through catastrophic bugs and attempt to keep executing something, on the assumption that major portions of your code aren't actually important anyway! No. No, no no. This is the road to unpredictable software, bugs that can never be reliably reproduced or tracked back to their original cause, shoddy software that works once, for the single scenario the developer tests under, but trashes the machines of half the end users. :sigh:
----
...the wind blows over it and it is gone, and its place remembers it no more...
Hahaha, like software isn't unpredictable already! And I'm not responsible for telling the computer what to do, the computer is responsible for doing what I ultimately want it to do. There's a difference. In a perfect world, where programmers were perfect beings and never made mistakes, what you're saying would be perfectly valid. But just think about it: if the computer (that is, the developers designing the system) took into account the potential for programmers to make mistakes, or simply to FORGET things, things might be a lot different. I'm not actually proposing this, but I just wanted to get people thinking about it in a different way. We're programming systems from the perspective that programmers ARE JUST LIKE PROGRAMS--that a programmer will write a program as accurately as a computer will execute it. But this isn't the case. Computers need to be designed from an interpretive perspective, like language. The English language (or any spoken language) is full of ambiguous, imprecise statements because that's how humans think. Why should we be forced to communicate with a computer any differently? ... I just read my last sentence and realized I'm opening myself to all kinds of flaming. So I'll cool down and pull back a little. All I want is for a null reference to be like "no object" so that if I execute a method on "no object" NOTHING HAPPENS! Maybe in some kind of debug mode it would give me a warning, or even an exception, but for production code, are we really saying that the program should break just because the code isn't written perfectly? I mean, what's more important here, that the program be perfect or that the user be able to use it? In my own defense, newer technologies are actually starting to see the benefit of this. Take WPF for instance. If you databind an object to a WPF control that does not support rendering the object, or cannot interpret it (for example in a list view hosting various types of objects), the program will not bomb on you. In fact nothing will happen at all, except that you'll get a silent message on the debug output window. Sure that little part of the program might not end up working, but it doesn't prevent the user from continuing to use the program. In fact it may not even be noticable to the user, and that's a heck of a lot better than throwing up an ugly Exception dialog, announcing to the world that the software basically sucks. I'd personally like to see a shift towards these kind of "silent" failures over big ugly error dialogs.