Ahmed El-Halwagy’s Blog

Archive for the ‘.NET’ Category

If you dealt with COM Interop before, then you probably know what Indexed Properties mean. If you don’t, hang on with me and you will know in the coming few lines. Consuming Indexed Properties is a new feature to C# 4.0 Beta2. This is used to improve syntax like the following:

var excel = new Microsoft.Office.Interop.Excel.ApplicationClass();


This syntax can now be improved to get rid of get_Range(“A1”) and use an indexer accessor instead, here’s how C# 4.0 Beta 2 can do for you to improve this:

var range = excel.Range[“A1”];

So now, every time you use COM Interop and have to call get_x() and set_x(), you can now replace this with the new indexer syntax. I have to tell you –Well, you might have guessed it- that this is just a syntatic sugar, the compiler will do emit calls to get_x() and set_x() ultimately.

I think this little syntax improvement is pretty neat, however, people shouldn’t ask the very expected question “Well, now we can consume indexed properties in c#, why can’t we create it? we wanna create indexed properties! Indexed properties is a legal right! blah blah .. “. If C# allowed us to create indexed properties then I think, this will add an ambiguity that isn’t worth anything here. I mean take a look at the following code and tell me what would it mean to you, if C# enables you to create indexed properties?


Does it mean that SomeProperty is a type that implements an indexer, or SomeProperty is a property that requires an indexer? See the ambiguity?


What’s your thoughts on this, dear reader?


In my last post when I linked
to a very interesting article on Eric Lippert’s blog.
Now I want to follow up on the subject of the post increment (++) operator.

Personally I used to think the the post increment operator will increment the value of its operand at the very end of the current
statement (i.e. just before the terminating “;”). So according to my understanding, this expression (x+(y++)+y) would evaluate to 0–
of course of both x and y were initialized to 0.

If you tried this example in the C# compiler you would find that the result of
the expression is 1! (yes not 0 :S). Obviously I was wrong! Here’s how I thought the sequence of evaluating this expression (z = x+(y++)+y;)
would go: First, x is added to y and the result is stored somewhere (a for example)
Second, the result of (#First) will be added to y again (note: y here is still 0, the increment didn’t happen yet)
and the result of this evaluation is stored somewhere (b for example)
Third, the assignment will happen; assigning the result of (#second “b”) to whatever on the left side of the “=” operator.
Fourth: Now (and only now) increment y. y = 1 now.

If this is right, I would get 0 as a result of Console.WriteLine(z); but it is NOT. This flow of evaluation is not correct.
My understanding of the
post increment operator is not right! (I’m doomed, eh!?).

So I checked up the c# documentation, still couldn’t find any specific statement
about when exactly the increment happens. After an hour on the internet, I turned to my favorite site, my
third place
now, Stackoverflow.com.

I logged in and posted a question.
Go ahead click the link and check the accepted answer, if you’re lazy, here’s my summary of the answer.

First you have to know that the ++ operator has an operation to perform with a specified precedence and a SIDE EFFECT. In short, the ++
operator has the higher precednce than (* + – /). See the specs
This means that the operator will execute instantly! Yes Instantly! So the increment will be the first thing to happen (even if it’s
post increment or pre-increment). The difference between pre and post comes from the side effect. When post incrementing the old value is
stored, then the increment happens (i.e. the value of the variable increments),
and the value that’s used to continue evaluating the expression is the (yeah, you guessed it) old value.

So to get back to the example (z = z +(y++) +y;), the order of evaluating this expression would be as follows:

  1. Store the value of y somwhere -say a. a now = 0.
  2. Increment y (remember the increment has the highest precednece).
  3. Add x to the value of a(which is the old value of y; that’s the side effect part of the operator) and save the result of
    the addition somewhere (say b). now b = 0;
  4. Add the value of b to the value of y (what’s the value of y now? yes you’re right, it’s 1), and store the result somewhere
    say c. say now = 1.
  5. Assign the value of c to z. z now = 1.

As you can see, the increment happens instantly. And its side effect forces the use of the old value of the incremented variable
for evaluating the very next part of the expression. After that when trying to dereference the incremented value and get its value,
you will actually get the incremented value.

Makes perfect sense to me now. What about you dear reader?

A while ago, when I posted my last post on this blog which was titles (Delegates and Events – A Look Back), I stated that it was an introduction to Lambda Expressions. Though it took me more than a month to re-blog again, here i’m continuing the journey on the C# 3.0 language enhancements features. The first thing we will discuss here is anonymous methods, as you know anonymous methods is just a shorthand way for subscribing to events and providing handlers all in one shot. The following code example shows the old way to subscribe to a Click event on a normal System.Windows.Forms.Button object.


This is the very classic way of subscribing to event. You simply need to provide a pre-defined delegate (in this case EventHandler) that points to a function matching a specific signature (in this case returns void and accepts two input parameters an System.Object parameter, and System.EventArgs parameter) . Using anonymous methods, life can be easier. Check out the next code sample.


As you can see here, all I needed to do in order to subscribe to the Click event on the Button object is to simply write my code that handles the event without having to define a whole new function just to handle this event, and also without having to know the event’s delegate signature.


Lambda expressions are another new way in C# 3.0 to substitute delegates in certain places. Now consider the following example, if you have a List<int>  and you want to filter this list and get only all the odd numbers out of it. One solution that might come handy is to use the FindAll method of your generic List<int>. FindAll expects one argument which in fact is of type System.Predicate<T>. System.Predicate<T> is a delegate that can point to any methods returns bool and takes a single argument T. The point is when FindAll was designed it was designed as this(take each item, check it, and then tell me if it should be included in the result set of the call).

The follwoing example illustrates the use of the smart FindAll method, take a look:


As you see here I’ve defined a method called IsOdd that takes a single integer parameter and returns a boolean value indicating whether the passed in parameter is odd or not. I then called the FindAll method on my list of integers (numbers) passing in a new Predicated delegate that points to IsOdd. What is going to happen here is my numbers list will take each element of it and pass it to the IsOdd(the method that the Predicate delegate points to) and check the value returned, if true, then the item will be added to the result set. If false then the item will be ignored. If you run the above code you will get the following result.


Now, what if you don’t want to define this whole IsOdd method that makes a really tiny job here and will not be reused by any other peace of code? Well, you guessed it, use anonymous method syntax like this:

A lambda expression is another handy way for providing an anonymous method. The syntax might seem clumsy at first, but once you get it, you never quit it 😉


What you see here is a lambda expression in action. The FindAll method expects a delegate and this time instead of passing it a delegate or an anonymous method I passed in well, a lambda, a lambda that will operate on one single integer parameter and return the the result of the expression x % 2 != 0.
The thing that most people find uncomfortable about lambdas is that, they can’t pronounce it, yeah, they write it but they can’t pronounce it. Our above example will be pronounce as follows (My only parameter will be processed this way “as what between the {} stats”).
A lambda expression can be in one of two forms; a single line form and a code block form. In our example we wrote a single statement in between two curly brackets, in fact I could have wrote any number of statements as needed. I will show you how lambda expressions can be appeared in a single line form:

Well that’s it for lambdas, any questions or suggestions feel absolutely free to leave a comment.


July 2018
« Nov    



Recent Twitter Updates