Какой самый странный случай из всех, что вы видели в C # или .NET? [закрыто]

Я собираю несколько угловых случаев и тизеров мозга и всегда хотел бы услышать больше. Страница действительно охватывает только биты и бобы языка C #, но я также нахожу основные вещи .NET тоже интересными. Например, вот то, чего нет на странице, но которое я считаю невероятным:

string x = new string(new char[0]);
string y = new string(new char[0]);
Console.WriteLine(object.ReferenceEquals(x, y));

Я ожидаю, что для печати False - в конце концов, «new» (со ссылочным типом) всегда создает новый объект, не так ли? Спецификации как для C #, так и для CLI указывают, что так и должно быть. Ну, не в этом конкретном случае. Он печатает True, и сделал это на каждой версии фреймворка, с которым я его тестировал. (Я не пробовал это на Моно, по общему признанию ...)

Просто чтобы прояснить, это всего лишь пример того, что я ищу - я не особенно искал обсуждения / объяснения этой странности. (Это не то же самое, что обычное интернирование строк; в частности, интернирование строк обычно не происходит при вызове конструктора.) Я действительно просил подобное странное поведение.

Есть еще какие-нибудь драгоценные камни?

Я думаю, что показывал вам это раньше, но мне здесь нравится веселье - это заняло некоторую отладку, чтобы выследить! (оригинальный код был явно более сложным и тонким ...)

    static void Foo<T>() where T : new()
    {
        T t = new T();
        Console.WriteLine(t.ToString()); // works fine
        Console.WriteLine(t.GetHashCode()); // works fine
        Console.WriteLine(t.Equals(t)); // works fine

        // so it looks like an object and smells like an object...

        // but this throws a NullReferenceException...
        Console.WriteLine(t.GetType());
    }

Так, что было T ...

Ответ: любой Nullable<T>- такой как int?. Все методы переопределены, кроме GetType (), который не может быть; поэтому он приводится (в штучной упаковке) к объекту (и, следовательно, к нулю) для вызова object.GetType () ... который вызывает null ;-p

Обновление: сюжет утолщается ... Ayende Rahien бросил аналогичный вызов в своем блоге , но с where T : class, new():

private static void Main() {
    CanThisHappen<MyFunnyType>();
}

public static void CanThisHappen<T>() where T : class, new() {
    var instance = new T(); // new() on a ref-type; should be non-null, then
    Debug.Assert(instance != null, "How did we break the CLR?");
}

Но это можно победить! Использование той же косвенности, которую используют такие вещи, как удаленное взаимодействие; предупреждение - следующее является чистым злом :

class MyFunnyProxyAttribute : ProxyAttribute {
    public override MarshalByRefObject CreateInstance(Type serverType) {
        return null;
    }
}
[MyFunnyProxy]
class MyFunnyType : ContextBoundObject { }

После этого new()вызов перенаправляется в прокси ( MyFunnyProxyAttribute), который возвращается null. А теперь иди и помой глаза!

Банковское округление.

Это не столько ошибка компилятора или сбой, но, конечно, странный случай ...

.Net Framework использует схему или округление, известное как округление банкира.

В округлении банкиров числа 0,5 округляются до ближайшего четного числа, поэтому

Math.Round(-0.5) == 0
Math.Round(0.5) == 0
Math.Round(1.5) == 2
Math.Round(2.5) == 2
etc...

Это может привести к некоторым неожиданным ошибкам в финансовых расчетах, основанных на более известном округлении до половины.

Это также верно для Visual Basic.

Что будет делать эта функция, если она вызывается как Rec(0)(не в отладчике)?

static void Rec(int i)
{
    Console.WriteLine(i);
    if (i < int.MaxValue)
    {
        Rec(i + 1);
    }
}

Ответ:

• В 32-битном JIT это должно привести к исключению StackOverflowException
• На 64-битном JIT он должен печатать все числа в int.MaxValue

Это связано с тем, что 64-разрядный JIT-компилятор применяет оптимизацию хвостового вызова , а 32-разрядный JIT - нет.

К сожалению, у меня нет 64-битной машины, чтобы проверить это, но метод отвечает всем условиям для оптимизации хвостового вызова. Если у кого-то есть такой, мне было бы интересно узнать, правда ли это.

Назначьте это!

Это то, что я люблю спрашивать на вечеринках (возможно, поэтому меня больше не приглашают):

Можете ли вы сделать следующий кусок кода скомпилировать?

    public void Foo()
    {
        this = new Teaser();
    }

Простой чит может быть:

string cheat = @"
    public void Foo()
    {
        this = new Teaser();
    }
";

Но реальное решение заключается в следующем:

public struct Teaser
{
    public void Foo()
    {
        this = new Teaser();
    }
}

Так что малоизвестно, что типы значений (структуры) могут переназначать свои thisпеременные.

Несколько лет назад, когда мы работали над программой лояльности, у нас возникла проблема с количеством баллов, начисляемых клиентам. Проблема была связана с приведением / преобразованием double в int.

В коде ниже:

double d = 13.6;

int i1 = Convert.ToInt32(d);
int i2 = (int)d;

i1 == i2 ?

Оказывается, что i1! = I2. Из-за различных политик округления в операторе Convert и cast действительные значения:

i1 == 14
i2 == 13

Всегда лучше вызывать Math.Ceiling () или Math.Floor () (или Math.Round с MidpointRounding, который отвечает нашим требованиям).

int i1 = Convert.ToInt32( Math.Ceiling(d) );
int i2 = (int) Math.Ceiling(d);

Они должны были сделать 0 целым числом, даже если перегружена функция enum.

Я знал обоснование команды ядра C # для отображения 0 в enum, но все же оно не так ортогонально, как должно быть. Пример из Npgsql .

Тестовый пример:

namespace Craft
{
    enum Symbol { Alpha = 1, Beta = 2, Gamma = 3, Delta = 4 };


   class Mate
    {
        static void Main(string[] args)
        {

            JustTest(Symbol.Alpha); // enum
            JustTest(0); // why enum
            JustTest((int)0); // why still enum

            int i = 0;

            JustTest(Convert.ToInt32(0)); // have to use Convert.ToInt32 to convince the compiler to make the call site use the object version

            JustTest(i); // it's ok from down here and below
            JustTest(1);
            JustTest("string");
            JustTest(Guid.NewGuid());
            JustTest(new DataTable());

            Console.ReadLine();
        }

        static void JustTest(Symbol a)
        {
            Console.WriteLine("Enum");
        }

        static void JustTest(object o)
        {
            Console.WriteLine("Object");
        }
    }
}

Это одна из самых необычных вещей, которые я когда-либо видел (кроме тех, что здесь, конечно!):

public class Turtle<T> where T : Turtle<T>
{
}

Он позволяет вам объявить это, но не имеет реального использования, так как он всегда будет просить вас обернуть любой класс, который вы наберете в центре, другой черепахой.

[шутка] Я предполагаю, что это черепахи полностью вниз ... [/ шутка]

Вот один, о котором я только недавно узнал ...

interface IFoo
{
   string Message {get;}
}
...
IFoo obj = new IFoo("abc");
Console.WriteLine(obj.Message);

Вышеприведенное выглядит на первый взгляд сумасшедшим, но на самом деле это законно. Нет, правда (хотя я пропустил ключевую часть, но это не что-то хакерское, вроде «добавить класс с именем IFoo» или «добавить usingпсевдоним в точку»).IFoo на класс").

Посмотрите, сможете ли вы выяснить почему: кто сказал, что вы не можете создать интерфейс?

Когда логическое значение не является ни истинным, ни ложным?

Билл обнаружил, что вы можете взломать логическое значение, так что если A - это True, а B - True, (A и B) - False.

Взломанные логические выражения

Я немного опаздываю на вечеринку, но у меня есть три четыре пять:

1. Если вы опрашиваете InvokeRequired для элемента управления, который не был загружен / показан, он скажет «ложь» - и взорвется вам в лицо, если вы попытаетесь изменить его из другого потока ( решение состоит в том, чтобы сослаться на это. Обращайтесь к создателю контроль).

2. Еще одна вещь, которая сбила меня с толку - это сборка с:

   enum MyEnum
   {
       Red,
       Blue,
   }

   если вы вычисляете MyEnum.Red.ToString () в другой сборке, и между тем кто-то перекомпилировал ваше перечисление в:

   enum MyEnum
   {
       Black,
       Red,
       Blue,
   }

   во время выполнения вы получите «черный».

3. У меня была общая сборка с несколькими удобными константами. Мой предшественник оставил массу уродливых свойств, доступных только для get, я думал, что избавлюсь от беспорядка и просто использую public const. Я был более чем удивлен, когда VS скомпилировал их с их значениями, а не ссылками.

4. Если вы реализуете новый метод интерфейса из другой сборки, но перестраиваете, ссылаясь на старую версию этой сборки, вы получаете исключение TypeLoadException (без реализации NewMethod), даже если вы его реализовали (см. Здесь ).

5. Словарь <,>: «Порядок возврата элементов не определен». Это ужасно , потому что это может иногда кусать вас, но работать на других, и если вы просто слепо предполагали, что Словарь будет играть хорошо («почему бы и нет? Я подумал, Список делает»), вам действительно нужно держи свой нос перед тем, как наконец начнешь сомневаться в своем предположении.

VB.NET, обнуляемый и троичный оператор:

Dim i As Integer? = If(True, Nothing, 5)

Это заняло у меня некоторое время для отладки, так как я ожидал iсодержатьNothing .

Что я на самом деле содержит? 0,

Это удивительно, но на самом деле «правильное» поведение: Nothingв VB.NET это не совсем то же самое, что nullв CLR: Nothingможет означать nullили default(T)тип значения T, в зависимости от контекста. В приведенном выше случае Ifвыводится Integerкак общий тип Nothingи 5, значит, в данном случае, Nothingозначает 0.

Я обнаружил второй действительно странный угловой корпус, который намного превосходит мой первый.

Метод String.Equals (String, String, StringComparison) фактически не имеет побочных эффектов.

Я работал над блоком кода, который содержал это в отдельной строке вверху какой-то функции:

stringvariable1.Equals(stringvariable2, StringComparison.InvariantCultureIgnoreCase);

Удаление этой строки приводит к переполнению стека в другом месте программы.

Код оказался установкой обработчика для того, что по сути было событием BeforeAssemblyLoad, и попыткой сделать

if (assemblyfilename.EndsWith("someparticular.dll", StringComparison.InvariantCultureIgnoreCase))
{
    assemblyfilename = "someparticular_modified.dll";
}

К настоящему времени я не должен был говорить тебе. Использование культуры, которая раньше не использовалась при сравнении строк, приводит к загрузке сборки. InvariantCulture не является исключением из этого.

Вот пример того, как вы можете создать структуру, которая вызывает сообщение об ошибке «Попытка чтения или записи защищенной памяти. Это часто указывает на то, что другая память повреждена». Разница между успехом и провалом очень тонкая.

Следующий модульный тест демонстрирует проблему.

Посмотрим, сможете ли вы решить, что пошло не так.

    [Test]
    public void Test()
    {
        var bar = new MyClass
        {
            Foo = 500
        };
        bar.Foo += 500;

        Assert.That(bar.Foo.Value.Amount, Is.EqualTo(1000));
    }

    private class MyClass
    {
        public MyStruct? Foo { get; set; }
    }

    private struct MyStruct
    {
        public decimal Amount { get; private set; }

        public MyStruct(decimal amount) : this()
        {
            Amount = amount;
        }

        public static MyStruct operator +(MyStruct x, MyStruct y)
        {
            return new MyStruct(x.Amount + y.Amount);
        }

        public static MyStruct operator +(MyStruct x, decimal y)
        {
            return new MyStruct(x.Amount + y);
        }

        public static implicit operator MyStruct(int value)
        {
            return new MyStruct(value);
        }

        public static implicit operator MyStruct(decimal value)
        {
            return new MyStruct(value);
        }
    }

C # поддерживает преобразования между массивами и списками, если массивы не являются многомерными, и между типами есть отношение наследования, а типы являются ссылочными типами.

object[] oArray = new string[] { "one", "two", "three" };
string[] sArray = (string[])oArray;

// Also works for IList (and IEnumerable, ICollection)
IList<string> sList = (IList<string>)oArray;
IList<object> oList = new string[] { "one", "two", "three" };

Обратите внимание, что это не работает:

object[] oArray2 = new int[] { 1, 2, 3 }; // Error: Cannot implicitly convert type 'int[]' to 'object[]'
int[] iArray = (int[])oArray2;            // Error: Cannot convert type 'object[]' to 'int[]'

Это самое странное, с чем я столкнулся случайно:

public class DummyObject
{
    public override string ToString()
    {
        return null;
    }
}

Используется следующим образом:

DummyObject obj = new DummyObject();
Console.WriteLine("The text: " + obj.GetType() + " is " + obj);

Выкину NullReferenceException. Оказывается, несколько дополнений компилируются компилятором C # для вызова String.Concat(object[]). До .NET 4 в этой перегрузке Concat была ошибка, когда объект проверяется на нулевое значение, но не результат ToString ():

object obj2 = args[i];
string text = (obj2 != null) ? obj2.ToString() : string.Empty;
// if obj2 is non-null, but obj2.ToString() returns null, then text==null
int length = text.Length;

Это ошибка ECMA-334 §14.7.4:

Бинарный оператор + выполняет конкатенацию строк, когда один или оба операнда имеют тип string. Если операнд конкатенации строк равен null, подставляется пустая строка. В противном случае любой нестроковый операнд преобразуется в его строковое представление, вызывая виртуальный ToStringметод, унаследованный от типа object. Если ToStringвозвращается null, подставляется пустая строка.

Интересно - когда я впервые посмотрел на это, я предположил, что это что-то, что проверял компилятор C #, но даже если вы генерируете IL напрямую, чтобы устранить любую возможность вмешательства, это все равно происходит, что означает, что это действительно newobjкод операции, который выполняет проверка.

var method = new DynamicMethod("Test", null, null);
var il = method.GetILGenerator();

il.Emit(OpCodes.Ldc_I4_0);
il.Emit(OpCodes.Newarr, typeof(char));
il.Emit(OpCodes.Newobj, typeof(string).GetConstructor(new[] { typeof(char[]) }));

il.Emit(OpCodes.Ldc_I4_0);
il.Emit(OpCodes.Newarr, typeof(char));
il.Emit(OpCodes.Newobj, typeof(string).GetConstructor(new[] { typeof(char[]) }));

il.Emit(OpCodes.Call, typeof(object).GetMethod("ReferenceEquals"));
il.Emit(OpCodes.Box, typeof(bool));
il.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new[] { typeof(object) }));

il.Emit(OpCodes.Ret);

method.Invoke(null, null);

Это также приравнивается к тому, trueчто вы проверяете, string.Emptyчто означает, что этот код операции должен иметь специальное поведение для интернирования пустых строк.

Public Class Item
   Public ID As Guid
   Public Text As String

   Public Sub New(ByVal id As Guid, ByVal name As String)
      Me.ID = id
      Me.Text = name
   End Sub
End Class

Public Sub Load(sender As Object, e As EventArgs) Handles Me.Load
   Dim box As New ComboBox
   Me.Controls.Add(box)          'Sorry I forgot this line the first time.'
   Dim h As IntPtr = box.Handle  'Im not sure you need this but you might.'
   Try
      box.Items.Add(New Item(Guid.Empty, Nothing))
   Catch ex As Exception
      MsgBox(ex.ToString())
   End Try
End Sub

Вывод «Попытка чтения защищенной памяти. Это признак того, что другая память повреждена».

PropertyInfo.SetValue () может назначать целые числа для перечислений, целые числа для пустых чисел, перечисления для пустых перечислений, но не целые для пустых перечислений.

enumProperty.SetValue(obj, 1, null); //works
nullableIntProperty.SetValue(obj, 1, null); //works
nullableEnumProperty.SetValue(obj, MyEnum.Foo, null); //works
nullableEnumProperty.SetValue(obj, 1, null); // throws an exception !!!

Полное описание здесь

Что если у вас есть универсальный класс, у которого есть методы, которые можно сделать неоднозначными в зависимости от аргументов типа? Я столкнулся с этой ситуацией, недавно написав двусторонний словарь. Я хотел написать симметричные Get()методы, которые возвращали бы противоположность любого передаваемого аргумента. Что-то вроде этого:

class TwoWayRelationship<T1, T2>
{
    public T2 Get(T1 key) { /* ... */ }
    public T1 Get(T2 key) { /* ... */ }
}

Все хорошо, если вы делаете экземпляр, где T1и T2есть разные типы:

var r1 = new TwoWayRelationship<int, string>();
r1.Get(1);
r1.Get("a");

Но если T1и T2то же самое (и, вероятно, если один был подклассом другого), это ошибка компилятора:

var r2 = new TwoWayRelationship<int, int>();
r2.Get(1);  // "The call is ambiguous..."

Интересно, что все остальные методы во втором случае все еще можно использовать; это только вызовы теперь неоднозначного метода, который вызывает ошибку компилятора. Интересный случай, если немного маловероятно и малоизвестно.

C # Accessibility Puzzler

Следующий производный класс обращается к закрытому полю из своего базового класса, и компилятор молча смотрит на другую сторону:

public class Derived : Base
{
    public int BrokenAccess()
    {
        return base.m_basePrivateField;
    }
}

Поле действительно личное:

private int m_basePrivateField = 0;

Хотите догадаться, как мы можем заставить такой код компилироваться?

,

,

,

,

,

,

,

Ответ

Хитрость заключается в том, чтобы объявить Derivedкак внутренний класс Base:

public class Base
{
    private int m_basePrivateField = 0;

    public class Derived : Base
    {
        public int BrokenAccess()
        {
            return base.m_basePrivateField;
        }
    }
}

Внутренние классы получают полный доступ к внешним членам класса. В этом случае внутренний класс также происходит от внешнего класса. Это позволяет нам «сломать» инкапсуляцию частных членов.

Просто сегодня нашел приятную мелочь:

public class Base
{
   public virtual void Initialize(dynamic stuff) { 
   //...
   }
}
public class Derived:Base
{
   public override void Initialize(dynamic stuff) {
   base.Initialize(stuff);
   //...
   }
}

Это выдает ошибку компиляции.

Вызов метода Initialize должен выполняться динамически, но не может быть потому, что он является частью выражения базового доступа. Рассмотрите приведение динамических аргументов или устранение базового доступа.

Если я напишу base.Initialize (материал как объект); это работает отлично, однако это кажется "волшебным словом" здесь, поскольку оно делает то же самое, все по-прежнему воспринимается как динамическое

В используемом нами API методы, которые возвращают объект домена, могут возвращать специальный «нулевой объект». В реализации этого оператор сравнения и Equals()метод переопределяются для возврата, trueесли он сравнивается сnull .

Таким образом, пользователь этого API может иметь такой код:

return test != null ? test : GetDefault();

или, возможно, немного более многословно, как это:

if (test == null)
    return GetDefault();
return test;

где GetDefault()это метод, возвращающий некоторое значение по умолчанию, которое мы хотим использовать вместо null. Удивление меня поразило, когда я использовал ReSharper и следовал рекомендациям переписать одно из следующего:

return test ?? GetDefault();

Если тестовый объект является нулевым объектом, возвращаемым из API, а не собственно null, поведение кода теперь изменилось, поскольку оператор объединения нулей фактически проверяет null, не запущен operator=или Equals().

Рассмотрим этот странный случай:

public interface MyInterface {
  void Method();
}
public class Base {
  public void Method() { }
}
public class Derived : Base, MyInterface { }

Если Baseи Derivedобъявлены в одной сборке, компилятор сделает Base::Methodвиртуальный и запечатанный (в CIL), даже еслиBase интерфейс не реализуется.

Если Baseи Derivedнаходятся в разных сборках, то при компиляции Derivedсборки компилятор не будет изменять другую сборку, поэтому он представит член, Derivedкоторый будет явной реализацией, для MyInterface::Methodкоторой будет просто делегирован вызов Base::Method.

Компилятор должен сделать это для поддержки полиморфной диспетчеризации в отношении интерфейса, то есть он должен сделать этот метод виртуальным.

Следующее может быть общим знанием, которого мне просто не хватало, но да. Некоторое время назад у нас был случай ошибки, который включал виртуальные свойства. Немного абстрагируя контекст, рассмотрите следующий код и примените точку останова к указанной области:

class Program
{
    static void Main(string[] args)
    {
        Derived d = new Derived();
        d.Property = "AWESOME";
    }
}

class Base
{
    string _baseProp;
    public virtual string Property 
    { 
        get 
        {
            return "BASE_" + _baseProp;
        }
        set
        {
            _baseProp = value;
            //do work with the base property which might 
            //not be exposed to derived types
            //here
            Console.Out.WriteLine("_baseProp is BASE_" + value.ToString());
        }
    }
}

class Derived : Base
{
    string _prop;
    public override string Property 
    {
        get { return _prop; }
        set 
        { 
            _prop = value; 
            base.Property = value;
        } //<- put a breakpoint here then mouse over BaseProperty, 
          //   and then mouse over the base.Property call inside it.
    }

    public string BaseProperty { get { return base.Property; } private set { } }
}

Находясь в Derivedконтексте объекта, вы можете получить то же поведение при добавлении base.Propertyв качестве часов или набравbase.Property в быстрые часы.

Мне потребовалось некоторое время, чтобы понять, что происходит. В конце концов я был просветлен Quickwatch. Когда вы входите в Quickwatch и исследуете Derivedобъект d (или из контекста объекта this) и выбираете поле base, поле редактирования в верхней части Quickwatch отображает следующее приведение:

((TestProject1.Base)(d))

Это означает, что если база будет заменена как таковая, вызов будет

public string BaseProperty { get { return ((TestProject1.Base)(d)).Property; } private set { } }

для часов, Quickwatch и отладочных подсказок при наведении курсора, и тогда имело бы смысл отображать их "AWESOME"вместо "BASE_AWESOME"рассмотрения полиморфизма. Я до сих пор не уверен, почему это превратило бы его в приведение, одна гипотеза которого callможет быть недоступна из контекста этих модулей, и толькоcallvirt .

В любом случае, это, очевидно, ничего не меняет с точки зрения функциональности, Derived.BasePropertyвсе равно действительно вернется "BASE_AWESOME", и, таким образом, это не было корнем нашей ошибки на работе, просто запутывающим компонентом. Однако мне было интересно, как это могло бы ввести в заблуждение разработчиков, которые не будут знать об этом во время их отладочных сессий, особенно если они Baseне представлены в вашем проекте, а скорее упоминаются как сторонние DLL, в результате чего разработчики просто говорят:

«Ой, подождите .. что? О боже, что это DLL, что-то смешное»

Это довольно сложно. Я столкнулся с этим, когда пытался создать реализацию RealProxy, которая действительно поддерживает Begin / EndInvoke (спасибо MS за то, что это невозможно без ужасных хаков). Этот пример в основном является ошибкой в ​​CLR, неуправляемый путь к коду для BeginInvoke не проверяет, что возвращаемое сообщение от RealProxy.PrivateInvoke (и мое переопределение Invoke) возвращает экземпляр IAsyncResult. Как только это возвращено, CLR становится невероятно запутанным и теряет любое представление о том, что происходит, как продемонстрировали тесты внизу.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Remoting.Proxies;
using System.Reflection;
using System.Runtime.Remoting.Messaging;

namespace BrokenProxy
{
    class NotAnIAsyncResult
    {
        public string SomeProperty { get; set; }
    }

    class BrokenProxy : RealProxy
    {
        private void HackFlags()
        {
            var flagsField = typeof(RealProxy).GetField("_flags", BindingFlags.NonPublic | BindingFlags.Instance);
            int val = (int)flagsField.GetValue(this);
            val |= 1; // 1 = RemotingProxy, check out System.Runtime.Remoting.Proxies.RealProxyFlags
            flagsField.SetValue(this, val);
        }

        public BrokenProxy(Type t)
            : base(t)
        {
            HackFlags();
        }

        public override IMessage Invoke(IMessage msg)
        {
            var naiar = new NotAnIAsyncResult();
            naiar.SomeProperty = "o noes";
            return new ReturnMessage(naiar, null, 0, null, (IMethodCallMessage)msg);
        }
    }

    interface IRandomInterface
    {
        int DoSomething();
    }

    class Program
    {
        static void Main(string[] args)
        {
            BrokenProxy bp = new BrokenProxy(typeof(IRandomInterface));
            var instance = (IRandomInterface)bp.GetTransparentProxy();
            Func<int> doSomethingDelegate = instance.DoSomething;
            IAsyncResult notAnIAsyncResult = doSomethingDelegate.BeginInvoke(null, null);

            var interfaces = notAnIAsyncResult.GetType().GetInterfaces();
            Console.WriteLine(!interfaces.Any() ? "No interfaces on notAnIAsyncResult" : "Interfaces");
            Console.WriteLine(notAnIAsyncResult is IAsyncResult); // Should be false, is it?!
            Console.WriteLine(((NotAnIAsyncResult)notAnIAsyncResult).SomeProperty);
            Console.WriteLine(((IAsyncResult)notAnIAsyncResult).IsCompleted); // No way this works.
        }
    }
}

Вывод:

No interfaces on notAnIAsyncResult
True
o noes

Unhandled Exception: System.EntryPointNotFoundException: Entry point was not found.
   at System.IAsyncResult.get_IsCompleted()
   at BrokenProxy.Program.Main(String[] args) 

Я не уверен, что вы скажете, что это странность Windows Vista / 7 или .Net, но я немного почесал голову.

string filename = @"c:\program files\my folder\test.txt";
System.IO.File.WriteAllText(filename, "Hello world.");
bool exists = System.IO.File.Exists(filename); // returns true;
string text = System.IO.File.ReadAllText(filename); // Returns "Hello world."

В Windows Vista / 7 файл фактически будет записан в C:\Users\<username>\Virtual Store\Program Files\my folder\test.txt

Вы когда-нибудь думали, что компилятор C # может генерировать недопустимый CIL? Запустите это, и вы получите TypeLoadException:

interface I<T> {
  T M(T p);
}
abstract class A<T> : I<T> {
  public abstract T M(T p);
}
abstract class B<T> : A<T>, I<int> {
  public override T M(T p) { return p; }
  public int M(int p) { return p * 2; }
}
class C : B<int> { }

class Program {
  static void Main(string[] args) {
    Console.WriteLine(new C().M(42));
  }
}

Я не знаю, как это происходит в компиляторе C # 4.0, хотя.

РЕДАКТИРОВАТЬ : это вывод из моей системы:

C:\Temp>type Program.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1 {

  interface I<T> {
    T M(T p);
  }
  abstract class A<T> : I<T> {
    public abstract T M(T p);
  }
  abstract class B<T> : A<T>, I<int> {
    public override T M(T p) { return p; }
    public int M(int p) { return p * 2; }
  }
  class C : B<int> { }

  class Program {
    static void Main(string[] args) {
      Console.WriteLine(new C().M(11));
    }
  }

}
C:\Temp>csc Program.cs
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.


C:\Temp>Program

Unhandled Exception: System.TypeLoadException: Could not load type 'ConsoleAppli
cation1.C' from assembly 'Program, Version=0.0.0.0, Culture=neutral, PublicKeyTo
ken=null'.
   at ConsoleApplication1.Program.Main(String[] args)

C:\Temp>peverify Program.exe

Microsoft (R) .NET Framework PE Verifier.  Version  3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

[token  0x02000005] Type load failed.
[IL]: Error: [C:\Temp\Program.exe : ConsoleApplication1.Program::Main][offset 0x
00000001] Unable to resolve token.
2 Error(s) Verifying Program.exe

C:\Temp>ver

Microsoft Windows XP [Version 5.1.2600]

В C # есть что-то действительно захватывающее, то, как он обрабатывает замыкания.

Вместо того чтобы копировать значения переменной стека в переменную без замыкания, он выполняет магическую обработку препроцессора, оборачивая все вхождения переменной в объект и, таким образом, перемещая ее из стека - прямо в кучу! :)

Я предполагаю, что это делает C # даже более функционально-полным (или лямбда-полным ху) языком, чем сам ML (который использует AFAIK для копирования значений стека). F # имеет такую ​​же функцию, как C #.

Это доставляет мне большое удовольствие, спасибо вам, ребята из MS!

Это не странный случай или случайный случай ... но что-то действительно неожиданное из языка VM на основе стека :)

Из вопроса, который я задал не так давно:

Условный оператор не может быть приведен неявно?

Дано:

Bool aBoolValue;

куда aBoolValue присваивается значение True или False;

Следующее не будет компилироваться:

Byte aByteValue = aBoolValue ? 1 : 0;

Но это будет:

Int anIntValue = aBoolValue ? 1 : 0;

Ответ также довольно хорош.

Область видимости в C # иногда бывает странной. Позвольте мне привести один пример:

if (true)
{
   OleDbCommand command = SQLServer.CreateCommand();
}

OleDbCommand command = SQLServer.CreateCommand();

Это не удается скомпилировать, потому что команда объявлена ​​повторно? Есть некоторые интересные догадки относительно того, почему это работает таким образом в этой теме на stackoverflow и в моем блоге .