Archive for the 'C#' Category

This is a bit off-topic, but bare with me 🙂

My good friend Yaniv just discovered something a bit wierd in C# 2005 regarding Nullable types.

Consider the following piece of code:

DateTime? modified;
modified = row.IsmodifiedNull() ?
null : row.modified;

What it basically does is sets null to “modified” if row.IsmodifiedNull() returns true or sets row.modified into “modified” if row.IsmodifiedNull() returns false.

This code cannot be compiled. The compiler yelled that it cannot set null to “modified” even though modified is defined as a Nullable type.

This code is actually equivalent to the abobe code, doesn’t use the “?” syntax and DOES compile:

if (row.IsmodifiedNull())
modified = null;
modified = row.modified;

After further investigation, Yaniv changed the code to the code below and it did work:

modified = row.IsmodifiedNull() ? (
Nullable<DateTime>)null : row.modified;

Its reasonable to assume that the “?” syntax is eventually translated in compile time into an “if” statement so why in a normal “if” statement setting “modified” to null works and in the “?” syntax it does not.

Bug? Feature?

I wonder who can comment on this.

Sorry for being off topic (again) but I just had to comment a bit on some of the comments that were posted for the previous post.

Eyal said that this feature was also added to Delphi 2005 and that its very good for portability issues. It seems that the guys at Borland used that quite a bit to map missing functions that were in .NET and not in Delphi’s VCL which made porting a lot easier.

It’s still a dirty hack and its can and probably WILL be used in a wrongful way.

Yaniv Golan added that the Extension Methods lacks namespace support, so if I have two Extension methods named the same way (due to a reference I’ve added or some other issue) we will get unexpected behavior? Should the compiler yell about that? Will it automatically select only one?

Yaniv suggested using the syntax that includes the namespace. So if I’m taking the example from my previous post instead of having:


I will have:


After all what will happen if someone adds some extension method and in a future version of the BCL (Basic Class Library) someone adds an extension method with a similar name?

Barry Kelly said that Extension methods were added because “It is absolutely required in order to extend IEnumerable to support the new query methods such as Max, Select etc.“.

Perhaps I don’t have the exact vision that Anders Hejlsberg has for C#, and you can call me old school if you wish, but I think that this whole LINQ thing could have been implemented as a certain type of framework.

Yes ADO (ActiveX Data Objects) wasn’t part of the language but most Visual Basic 6 users were able to use it with little to no effort. So it wasn’t part of the language and the compiler didn’t understand a thing about it. So what?!

As far as I know (and people, please correct me if I’m wrong) the compiler can only check the syntax correctness of the statement but can’t perform any other checks at compile time.
Yes, this syntrax might be a bit more intuitive but I’m quite sure this could have been made without brutally hacking the compiler and adding these features.

What’s wrong with a syntax like:

int[] numbers = { 2,2,2,4,5 };
int count = LINQ.Count(LINQ.Distinct(numbers));

I also wonder what happend to the whole XQuery idea? I remember Microsoft releasing an XQuery implementation? XQuery is a language that can be used not only for XML querying but to query and intersect information from various places much like LINQ’s features.

I might be missing the vision of marrying data access with the language itself, but I really don’t think this is the MOST necessary feature that will boost productivity and will ascend to a level of a killer feature.

I know this is a bit off topic, but I just had to comment about it here.

Since I was not able to attend to PDC I’ve been hearing a lot about the announcements and new stuff coming out of it.

One of these things is some of the features in C# 3.0 spec called “Extension Methods”.
In short, Extension Methods allows you to extend an existing class that is sealed by creating a class that has a static function with a special syntax which allows you to call that function on an instance of that object as if it was a member function.

For example, if I want to extend the the String class (which, as you all know, is a sealed class and has its reasons to be like that which I won’t get into at the moment) I would create a class like this:

public static class MyExtension {
public static void Foo(this string s) {
Console.WriteLine(“MyExtension::Foo = {0}”, s);

Notice the “this” keyword near the function’s parameter. This is the keyword that does the magic.

To invoke this method I would use the following syntax:

string s = “Testing Extensions”;

You see, it looks like the String class always had a method named Foo.

Now as much as some people think this feature is cool I don’t see the point of actually having it and showing it like a big thing.

This “functionality” could have been used in previous version of C#. In previous version all you had to do is this:

public static class MyExtension {
public static void Foo(string s) {
Console.WriteLine(“MyExtension::Foo = {0}”, s);

and invoke the code like this:

string s = “Testing Extensions”;

Which, in my opinion, is a lot clearer when reading this code since I know that there is a class somewhere in the code (either from a reference or inside the same .cs file or in another .cs file in the project) that is called MyExtension and have a method called Foo.

So why do we need this functionality?

I guess we don’t, but the only reason I can think of came to me from seeing all the examples out there which involves the String class. Perhaps because the String class (and a few other classes in the Base Class Library (BCL)) are sealed, some people whined too much about it and someone decided on adding this to make them get the same feel as if they inherited from a sealed class and extended it.

Now I know that the C# Spec is saying: “Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible.”

But what I do know is that every feature which is not very specific and limited and can be used in a wrongful way, WILL be used in a wrongful way.

So the main question here is, why add such a feature if there are a LOT of other features that are more needed and can get a enchance productivity?

(I wonder how can one get into the language design meetings or at least for the review process of the specs before they are submitted 😉 ).

I was working today on figuring out some Managed C++ code with a friend from work (Oran Singer) and I just wanted to outline some of the oddities of the Managed C++ Destructors because I think it is important for everyone to understand how they work and what some of the quirks about them are.

We are still in the middle of figuring out something more serious (I will post on that later on).

I would like to “appologize” to the C#/VB.NET crowed in advance since this post is all about Managed C++ today a bit on its future, but I think it will be interesting none-the-less.

First of all, a Managed C++ class that had a destructor will include two additional methods due to the destructor:

  1. Finalize method
  2. __dtor method

Currently you cannot implement the finalize method in managed C++ directly like in C# by simply override it since it is defined as private protected in System::Object so the only way to do it is to add a destructor to the class.

This means that a Managed C++ class that has a destructor has a finalizer with all the implications of a .NET finalizer (I’ve written in more detail about finalizers here).

The __dtor is being called when you use the “delete” operator on a managed C++ class instance (IMPORTANT NOTE: You can only call “delete” on a managed C++ class instance that implements a destructor).

The implementation of the __dtor method is similar to an implementation one would put in a Dispose method when implementing the IDisposable interface. It has two function calls, one to GC.SuppressFinalize (so the finalizer thread will ignore calling the Finalize method of this instance) and a call to Finalize (to actually perform the destructor code).

Another interesting anecdote is that if you have a pure virtual class and you add a constructor to it, it must have a body even though this is a pure virtual class since there is always a virtual call to the base class’s destructor.

Looking a bit to the future, in Visual Studio 2005 (previously known as Whidbey) Visual C++ that generates managed code get a few new features that are a bit different in implementation than what we saw above.

First of all, when implementing only a destructor (“~MyClass()”) the compiler will actually fully implement the IDisposable interface and in certain cases will automatically call the Dispose method (in C# you would either use try..finally block and call the Dispose at the finally part or use the “using” keyword) in the following cases:

  • A stack based object goes out of scope
  • A class member’s enclosing object is destroyed
  • A delete is performed on the pointer or handle.

In addition to that you can explicitly implement a finalizer using the “!” tag (“!MyClass()”). That finalizer is subject to that usual finalizer rules we already know. The main advantage is that it will NOT run if you already called the destructor.

These new features allows improved control for a more deterministic cleanup and allows finer control on C++ managed objects that was previously not available.

I would like to thank Oran again for his help, mainly for forcing me to search some more on the subject and getting the idea to write this post.