Який найдивніший кутовий випадок, який ви бачили в 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, і робиться на кожній версії рамки, з якою я його тестував. (Я не пробував цього на Mono, правда, ...)

Щоб було зрозуміло, це лише приклад того, що я шукаю - я не особливо шукав обговорення / пояснення цієї дивацтва. (Це не те саме, що звичайне строкове інтернування; зокрема, інтернування інтернету зазвичай не відбувається, коли викликається конструктор.) Я дійсно просив подібної дивної поведінки.

Будь-які інші дорогоцінні камені там ховаються?

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

    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());
    }

Отже, що було Т ...

Відповідь: будь-яка Nullable<T>- наприклад int?. Усі методи перекриваються, за винятком GetType (), якого не може бути; тому він передається (у коробці) об'єкту (а значить, і до нуля) для виклику object.GetType () ... який викликає null ;-p

Оновлення: сюжет згущується ... Ейенде Рахіен кинула подібний виклик у своєму блозі , але з 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змінну.

Кілька років тому, працюючи над програмою лояльності, у нас виникло питання щодо кількості балів, наданих клієнтам. Проблема стосувалася кастингу / перетворення подвійних в int.

У коді нижче:

double d = 13.6;

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

i1 == i2 ?

Виходить, що i1! = I2. Через різні політики округлення в операторі «Перетворити і відкинути» фактичні значення:

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 цілим числом, навіть якщо є перевантаження функції перерахунку.

Я знав обґрунтування основної команди C # для відображення 0 на перерахунок, але все-таки це не настільки ортогонально, як має бути. Приклад з 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 - це правда, а B - це правда, (A і B) є хибним.

Зламані булеви

Я приїжджаю трохи пізно на вечірку, але в мене є три чотири п'ять:

1. Якщо ви опитуєте InvokeRequired на контрольному елементі, який не завантажений / показаний, він скаже помилкове - і вибухне вам в обличчя, якщо ви спробуєте змінити його з іншого потоку ( рішення - посилатися на це. контроль).

2. Ще одне, що мене наштовхнуло, - це те, що дали збірку з:

   enum MyEnum
   {
       Red,
       Blue,
   }

   якщо ви обчислюєте MyEnum.Red.ToString () в іншій збірці, а між ними хтось перекомпілює ваш перелік:

   enum MyEnum
   {
       Black,
       Red,
       Blue,
   }

   під час виконання, ви отримаєте "Чорний".

3. У мене було спільне зібрання з деякими зручними константами. Мій попередник залишив безліч некрасивих властивостей для отримання лише я, я думав, що я позбудуся брязкальця і ​​просто використовувати публічну константність. Я був більш ніж трохи здивований, коли В. С. склав їх за своїми значеннями, а не посиланнями.

4. Якщо ви реалізуєте новий метод інтерфейсу з іншої збірки, але ви відновлюєте посилання на стару версію цієї збірки, ви отримуєте TypeLoadException (не реалізація 'NewMethod'), навіть якщо ви його реалізували (див. Тут ).

5. Словник <,>: "Порядок повернення елементів не визначений". Це жахливо , тому що іноді може вкусити тебе, але працювати іншим, і якщо ти просто сліпо припустив, що Словник буде грати добре ("чому не варто? Я думав, Ліст робить"), ти справді повинен покладіть ніс у нього, перш ніж ви нарешті почнете ставити під сумнів своє припущення.

VB.NET, нульові і термінальний оператор:

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

Це зайняло у мене деякий час, щоб налагодити, оскільки я очікував, що iвони містять Nothing.

Що я насправді містить? 0.

Це дивно, але насправді "правильна" поведінка: NothingVB.NET не зовсім такий, як nullу CLR: Nothingможе означати nullабо default(T)для типу значення T, залежно від контексту. У наведеному вище випадку Ifвисновок Integerяк загальний тип Nothingі 5, отже, в даному випадку Nothingозначає 0.

Я знайшов другий справді дивний кутовий корпус, який б’є мій перший дальнім пострілом.

Метод String.Equals (String, String, StringComppare) насправді не є побічним ефектом.

Я працював над блоком коду, який мав це в рядку сам по собі вгорі деякої функції:

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, де об'єкт перевіряється на null, але не є результатом 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 # перевіряє, але навіть якщо ви випромінюєте ІЛ безпосередньо, щоб усунути будь-який шанс втручання, це все-таки трапляється, це означає, що це дійсно 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 () може присвоювати ints enums, ints nullable ints, enums to nulible enums, але не ints to nulible enums.

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 # Доступність 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);
   //...
   }
}

Це кидає помилку компіляції.

Виклик методу "Ініціалізувати" потрібно динамічно відправляти, але не може бути, тому що він є частиною виразу базового доступу. Розгляньте можливість введення динамічних аргументів або усунення базового доступу.

Якщо я напишу 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 та вивчення Derivedоб'єкта d (або з контексту об'єкта this) та вибору поля base, поле редагування у верхній частині Quickwatch відображає такий склад:

((TestProject1.Base)(d))

Що означає, що якщо база буде замінена як така, то дзвінок був би

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

для інструментів "Годинники", "Швидкий годинник" та налагодження миші за налагодженням, і тоді це має сенс відображати "AWESOME"замість того, "BASE_AWESOME"щоб розглянути питання про поліморфізм. Я все ще не впевнений, чому це перетворило б його в склад, одна з гіпотез - це callможе бути недоступно лише з контексту цих модулів callvirt.

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

"Ой, зачекайте. Що? Омг, схожий на DLL, .. роблячи щось смішне"

Це досить важко вдосконалити. Я наткнувся на це, коли я намагався створити реалізацію RealProxy, яка справді підтримує Begin / EndInvoke (дякую MS, що зробили це неможливо без жахливих хак). Цей приклад в основному є помилкою в CLR, шлях некерованого коду для BeginInvoke не підтверджує, що повідомлення, що повертається з RealProxy.PrivateInvoke (і мій Invoke override) повертає екземпляр 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.

EDIT : це вихід з моєї системи:

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призначено або Істинне, або Неправильне;

Наступне не компілюється:

Byte aByteValue = aBoolValue ? 1 : 0;

Але це:

Int anIntValue = aBoolValue ? 1 : 0;

Надана відповідь теж досить хороша.

Оцінка рівня в c # часом справді химерна. Дозвольте навести один приклад:

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

OleDbCommand command = SQLServer.CreateCommand();

Це не вдалося компілювати, тому що команда передекларована? Є кілька зацікавлених здогадок щодо того, чому він працює таким чином у цій темі на stackoverflow та в моєму блозі .