I don't know what actually transpired, but I do know that generics require changes in the CLR - it's not just within the scope of C#. So, it may have been out of his hands. I am certainly glad that we will finally get generics in dotnet. Transitioning
from C++ to C# was quite painful because there were no templates.

One of the first things that caught my attention when learning C# was the dependencies it has on the framework.
For example, the using construct "knows about" the IDisposable interface, foreach knows about IEnumerable (well, GetEnumerator at least), lock knows about Monitor, and the list goes on.
This is a clear departure from C++, where the language is well isolated from whatever code the user writes.
I suppose that with support for reflection and boxing, it may have been unavoidable. Am I the only one who felt a little uncomfortable with that?

Don Syme and Andrew Kennedy from MSR Cambridge came up with
the implementation techniques used for .NET generics - and they beat pretty much everything else out there in terms of expressibility, speed, and performance. Note that the original paper is from 2001: it can take a LONG time to take a good idea from research
and get it into the hands of customers!

I agree that C# and the framework were closely tied together during their development and various features of one influenced the other. However, I don’t believe those features of C# as a language are as tightly coupled with the framework features as you
mentioned. Those are just the implementation details of C# on the .NET platform. The ‘using’ construct means “free up this resource after this block exits”. From the language perspective it doesn’t matter how it goes about freeing the resource, just that it
frees it. Similarly, the ‘lock’ keyword is a generic (relatively) thread synchronization feature. It just so happens that the C# .NET compiler uses a Monitor to achieve that. Same goes for the foreach statement. It’s to iterate over a collection. The fact
that the compiler translates that into the whole IEnumerable deal is a platform implementation detail.

In other words, C# using, lock, and foreach know nothing about IDisposable, Monitor, and IEnumerator any more than the C++ operators new and delete know about the CRT malloc and free functions that will likely get called as a result of those operators.

Regarding C++'s new and delete, I can almost agree, but I think they carefully side-stepped the issue. I could write a custom allocator, and then I wouldn't need to even link with the runtime.

In the CLR, I think they have also carefully side-stepped the dependencies. The 'box' instruction, for example, has to specify a type handle to the boxed type you want returned. So, you could (in theory at least) write your own Int32 struct and use it instead
of the framework's.

However, C# doesn't seem to side-step the dependency. In the docs for 'using', it states: "The object you instantiate must implement the System.IDisposable interface." This is in contrast to the docs for 'foreach', where it seems that the issue was side-stepped:
"Evaluates to a type that implements IEnumerable or a type that declares a GetEnumerator method."

I haven't tested the statements in MSDN's 'using' page against the actual implementation, so it may be that the docs are just wrong.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.