Dot Net Deewane

I first saw this on  Ayende's blog  (in a rather more obscure form, admittedly). Once again, work out what will be printed, and why. using  System; class  Test {      static   void  Main()     {         Foo( "Hello" );     }          static   void  Foo( object  x)     {         Console.WriteLine( "object" );     }          static   void  Foo<T>( params  T[] x)     {         Console.WriteLine( "params T[]" );     } } Answer:   params T[]  is printed. Now why would the compiler choose to create an array when it doesn't have to? Well... there are two stages to this. Firstly, ...

Should this code compile? Does it? What does it mean? using  System; class  Test {      enum  Foo { Bar, Baz };          static   void  Main()     {         Foo f = 0.0;         Console.WriteLine(f);     } } Answer:  This shouldn't compile, but it does under the MS compilers for both C# 2 and 3 (and probably 1 as well - I haven't checked). It shouldn't compile because only the literal 0 should be implicitly convertible to the default value of any enum. Here the decimal is 0.0. Just a little compiler bug. The result is to print  Bar  as that's the 0 value of the  Foo .

Here's some code using the anonymous method feature of C# 2. What does it do? using  System; using  System.Collections.Generic; class  Test {      delegate   void  Printer();          static   void  Main()     {         List<Printer> printers =  new  List<Printer>();          for  ( int  i=0; i < 10; i++)         {             printers.Add( delegate  { Console.WriteLine(i); });         }                  foreach  (Printer printer  in  printers)        ...

Computers are meant to be good at arithmetic, aren't they? Why does this print "False"? double  d1 = 1.000001; double  d2 = 0.000001; Console.WriteLine((d1-d2)==1.0); Answer:  All the values here are stored as binary floating point. While 1.0 can be stored exactly, 1.000001 is actually stored as 1.0000009999999999177333620536956004798412322998046875, and 0.000001 is actually stored as 0.000000999999999999999954748111825886258685613938723690807819366455078125. The difference between them isn't exactly 1.0, and in fact the difference can't be stored exactly either.

What will be displayed, why, and how confident are you? using  System; class  Foo {      static  Foo()     {         Console.WriteLine ( "Foo" );     } } class  Bar {      static   int  i = Init();          static   int  Init()     {         Console.WriteLine( "Bar" );          return  0;     } } class  Test {      static   void  Main()     {         Foo f =  new  Foo();         Bar b =  new  Bar();     } } Answer:  On my box,  Bar  is printed an...

What is displayed, and why? using  System; class  Base {      public   virtual   void  Foo( int  x)     {         Console.WriteLine ( "Base.Foo(int)" );     } } class  Derived : Base {      public   override   void  Foo( int  x)     {         Console.WriteLine ( "Derived.Foo(int)" );     }          public   void  Foo( object  o)     {         Console.WriteLine ( "Derived.Foo(object)" );     } } class  Test {      static   void  Main()     {         Derived...

“We need a database therefore we need SQL Server.” How many times have you heard this? This is so often the default position for people wanting to persist data on the server and as the old adage goes, this is the hammer to every database requirement which then becomes the nail. SQL Server has simply become “the standard” for many people. SQL Server is a beast. It does a lot.     It’s awesome at what it does, but it   always  does more than I actually need. Azure Table Storage is simple, at least relatively speaking. You have a table, it’s partitioned, it has rows. You put stuff into that table then you query is back out, usually by referencing the partition and row keys. One of the things that attracted me to Table Storage is that it’s not constrained to a server or a VM or any logical construct that’s governed by finite resources (at least not “finite” within a reasonable definition), rather it’s a service. You don’t pay for CPU and RAM or put it on a parti...

IQueryable<T> is intended to allow a query provider (for example, an ORM like LINQ to SQL or the Entity Framework) to use the expressions contained in a query to translate the request into another format. In other words, LINQ-to-SQL looks at the properties on the entities that you're using along with the comparisons you're making and actually creates a SQL statement to express (hopefully) an equivalent request. IEnumerable<T> is more generic than IQueryable<T> (though all instances of IQueryable<T> implement IEnumerable<T>) and only defines a sequence. However, there are extension methods available within the Enumerable class that define some query-type operators on that interface and use ordinary code to evaluate these conditions. List<T> is just an output format, and while it implements IEnumerable<T>, is not directly related to querying. In other words, when you're using IQueryable<T>, you're defining and express...

An application can often increase performance by storing data in memory that is accessed frequently and that requires significant processing time to create. For example, if your application processes large amounts of data using complex logic and then returns the data as a report accessed frequently by users, it is efficient to avoid re-creating the report every time that a user requests it. Similarly, if your application includes a page that processes complex data but that is updated only infrequently, it is inefficient for the server to re-create that page on every request. To help you increase application performance in these situations, ASP.NET provides caching using two basic caching mechanisms. The first is application caching, which allows you to cache data you generate, such as a   DataSet   object or a custom report business object. The second is page output caching, which saves the output of page processing and reuses the output instead of re-processing the page w...