C# Hidden Optimizations(gavindraper.co.uk)

8 pointsby gavdraper16 lat temu14 comments

gavindraper.co.uk

http://www.gavindraper.co.uk/blog/2010/08/10/CHiddenOptimizations.aspx

15 comments

heresy16 lat temu

Nit: These aren't "optimizations", they're syntactic sugar.

achew2216 lat temu

I'm far from impressed with this. How is ?? any different from a guard ( || )? I use that all the freaking time in every language. I've never written a line of C# and even I know about the parallel module, how didn't that make the cut?

mullr16 lat temu

C# has || just like any other language, but objects aren't truthy and nulls aren't falsy. This was a good design decision, since it catches the common = vs. == error if(a=b) while doing the type check rather than silently doing the (probably) wrong thing. As a consequence, the || doesn't work as it does in other places. Hence ??.

steverb16 lat temu

?? is the null coalescing operator and it's neither new nor is it hidden.

It is damned handy though.

newt16 lat temu

Every language?

Java, as far as I know, does not allow if (someObject) where someObject is a class type. AFIAK, java only allows that if someObject is a bool, or possibly an int as well.

In strongly typed languages in general, null is not the same thing as false and not-null is not the same thing as true.

oozcitak16 lat temu

I would say expression trees is one of the less well-known and under-appreciated features of C# 3.0:

    Expression<Func<int, int>> e = (x) => x + 1;
    Func<int, int> f = e.Compile();
    int b = f.Invoke(42);

arethuza16 lat temu

I'm quite fond of C# but that syntax is a bit much when compared to things like humble old JavaScript:

   var f = function(x) { return x + 1; };
   var b = f(42);

newt16 lat temu

The Expression tree part is powerful (you can inspect it with code, pull property names out, etc), but it's not needed in most cases. Your example in C# is:

  Func<int, int> f = x => x + 1;
  int b = f(42);

This is shorter than the JavaScript. The C# is more verbose where has to specify a type for f because it cannot work it out from context (in fact the left side of the '=' supplies type information to the right side), but the actual expression on the right is less verbose than the JavaScript with its "function" and "return" keywords.

If you want, the second line can be

  var b = f(42);

But it's the same number of chars. I don't think that you gain anything from letting the compiler work out that b is an int.

profquail16 lat temu

The best thing about expression trees isn't that it lets you declare a method like Func<Func<int>, int> = ... (or whatever), but that you can inspect (and modify) the expression tree at runtime. This is what powers LINQ, and the 'static reflection' used by fluent APIs like Fluent nHibernate.

yread16 lat temu

well you can write it as

  var f = ((x) => x + 1).Compile();
  int b = f.Invoke(42);

oozcitak16 lat temu

I don't think that would work. How would the compiler know the type of x and the return type of the lambda expression?

the_rara_avis16 lat temu

It won't. In just about all cases, C# doesn't do backtracking to infer types. See Eric Lippert's posts: http://blogs.msdn.com/b/ericlippert/archive/2010/10/04/no-ba...

[deleted]16 lat temu

newt16 lat temu

This article is Ok, in an introductory sort of way, but these are not "optimizations" in the sense that they will make your code run faster. They're syntactic sugar as heresy says.

They're also not very hidden either.

Rickasaurus16 lat temu

How did this garbage get on the HN front page?