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

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

    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 (), которого не может быть; поэтому он приводится (помещается в коробку) к объекту (и, следовательно, к null) для вызова 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. А теперь иди и промой глаза!

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

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

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

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

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

В Bankers 'Rounding числа 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.

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

(Я не говорю о переопределенном операторе равенства в строковом классе)

Интересно - когда я впервые посмотрел на это, я предположил, что это то, что проверяет компилятор 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, что означает, что этот код операции должен иметь особое поведение для вставки пустых строк.

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

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

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

Что будет делать эта функция при вызове 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-битной машины, чтобы проверить это, но метод действительно удовлетворяет всем условиям для оптимизации хвостового вызова. Если у кого-то есть, мне было бы интересно узнать, правда ли это.

Следующее выводит False вместо исключения переполнения:

Console.WriteLine("{0}", yep(int.MaxValue ));


private bool yep( int val )
{
    return ( 0 < val * 2);
}

Этот меня по-настоящему озадачил (прошу прощения за длину, но это WinForm). Я недавно разместил это в группы новостей.

I've come across an interesting bug. I have workarounds but i'd like to know the root of the problem. I've stripped it down into a short file and hope someone might have an idea about what's going on.

It's a simple program that loads a control onto a form and binds "Foo" against a combobox ("SelectedItem") for it's "Bar" property and a datetimepicker ("Value") for it's "DateTime" property. The DateTimePicker.Visible value is set to false. Once it's loaded up, select the combobox and then attempt to deselect it by selecting the checkbox. This is rendered impossible by the combobox retaining the focus, you cannot even close the form, such is it's grasp on the focus.

I have found three ways of fixing this problem.

a) Remove the binding to Bar (a bit obvious)

b) Remove the binding to DateTime

c) Make the DateTimePicker visible !?!

I'm currently running Win2k. And .NET 2.00, I think 1.1 has the same problem. Code is below.

using System;
using System.Collections;
using System.Windows.Forms;

namespace WindowsApplication6
{
    public class Bar
    {
        public Bar()
        {
        }
    }

    public class Foo
    {
        private Bar m_Bar = new Bar();
        private DateTime m_DateTime = DateTime.Now;

        public Foo()
        {
        }

        public Bar Bar
        {
            get
            {
                return m_Bar;
            }
            set
            {
                m_Bar = value;
            }
        }

        public DateTime DateTime
        {
            get
            {
                return m_DateTime;
            }
            set
            {
                m_DateTime = value;
            }
        }
    }

    public class TestBugControl : UserControl
    {
        public TestBugControl()
        {
            InitializeComponent();
        }

        public void InitializeData(IList types)
        {
            this.cBoxType.DataSource = types;
        }

        public void BindFoo(Foo foo)
        {
            this.cBoxType.DataBindings.Add("SelectedItem", foo, "Bar");
            this.dtStart.DataBindings.Add("Value", foo, "DateTime");
        }

        /// <summary>
        /// Required designer variable.
        /// </summary>
        private System.ComponentModel.IContainer components = null;

        /// <summary>
        /// Clean up any resources being used.
        /// </summary>
        /// <param name = "disposing">true if managed resources should be disposed; otherwise, false.</param>
        protected override void Dispose(bool disposing)
        {
            if (disposing && (components != null))
            {
                components.Dispose();
            }
            base.Dispose(disposing);
        }

        #region Component Designer generated code

        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {
            this.checkBox1 = new System.Windows.Forms.CheckBox();
            this.cBoxType = new System.Windows.Forms.ComboBox();
            this.dtStart = new System.Windows.Forms.DateTimePicker();
            this.SuspendLayout();
            //
            // checkBox1
            //
            this.checkBox1.AutoSize = true;
            this.checkBox1.Location = new System.Drawing.Point(14, 5);
            this.checkBox1.Name = "checkBox1";
            this.checkBox1.Size = new System.Drawing.Size(97, 20);
            this.checkBox1.TabIndex = 0;
            this.checkBox1.Text = "checkBox1";
            this.checkBox1.UseVisualStyleBackColor = true;
            //
            // cBoxType
            //
            this.cBoxType.FormattingEnabled = true;
            this.cBoxType.Location = new System.Drawing.Point(117, 3);
            this.cBoxType.Name = "cBoxType";
            this.cBoxType.Size = new System.Drawing.Size(165, 24);
            this.cBoxType.TabIndex = 1;
            //
            // dtStart
            //
            this.dtStart.Location = new System.Drawing.Point(117, 40);
            this.dtStart.Name = "dtStart";
            this.dtStart.Size = new System.Drawing.Size(165, 23);
            this.dtStart.TabIndex = 2;
            this.dtStart.Visible = false;
            //
            // TestBugControl
            //
            this.AutoScaleDimensions = new System.Drawing.SizeF(8F, 16F);
            this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
            this.Controls.Add(this.dtStart);
            this.Controls.Add(this.cBoxType);
            this.Controls.Add(this.checkBox1);
            this.Font = new System.Drawing.Font("Verdana", 9.75F,
            System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point,
            ((byte)(0)));
            this.Margin = new System.Windows.Forms.Padding(4);
            this.Name = "TestBugControl";
            this.Size = new System.Drawing.Size(285, 66);
            this.ResumeLayout(false);
            this.PerformLayout();

        }

        #endregion

        private System.Windows.Forms.CheckBox checkBox1;
        private System.Windows.Forms.ComboBox cBoxType;
        private System.Windows.Forms.DateTimePicker dtStart;
    }

    public class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            this.Load += new EventHandler(Form1_Load);
        }

        void Form1_Load(object sender, EventArgs e)
        {
            InitializeControl();
        }

        public void InitializeControl()
        {
            TestBugControl control = new TestBugControl();
            IList list = new ArrayList();
            for (int i = 0; i < 10; i++)
            {
                list.Add(new Bar());
            }
            control.InitializeData(list);
            control.BindFoo(new Foo());
            this.Controls.Add(control);
        }

        /// <summary>
        /// Required designer variable.
        /// </summary>
        private System.ComponentModel.IContainer components = null;

        /// <summary>
        /// Clean up any resources being used.
        /// </summary>
        /// <param name = "disposing">true if managed resources should be disposed; otherwise, false.</param>
        protected override void Dispose(bool disposing)
        {
            if (disposing && (components != null))
            {
                components.Dispose();
            }
            base.Dispose(disposing);
        }

        #region Windows Form Designer generated code

        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {
            this.components = new System.ComponentModel.Container();
            this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
            this.Text = "Form1";
        }

        #endregion
    }

    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }
    }
}

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[]'

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

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

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

   enum MyEnum
   {
       Red,
       Blue,
   }
   

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

   enum MyEnum
   {
       Black,
       Red,
       Blue,
   }
   

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

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

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

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

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

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

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

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

Несколько лет назад при работе над программой лояльности у нас возникла проблема с количеством начисляемых клиентам баллов. Проблема была связана с приведением / преобразованием double в 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 в 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");
        }
    }
}

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

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

OleDbCommand command = SQLServer.CreateCommand();

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

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

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

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

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

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

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

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

[шутка] Думаю, это черепахи ... [/ шутка]

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

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

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

stringvariable1.Equals(stringvariable2, StringComparison.InvariantCultureIgnoreCase);

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

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

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

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

VB.NET, значения NULL и тернарный оператор:

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.

PropertyInfo.SetValue () может присваивать целые числа перечислениям, целые числа - целым значениям, допускающим значение NULL, перечисления - перечислениям, допускающим значение NULL, но не целым числам - перечислениям, допускающим значение NULL.

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 !!!

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

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

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

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

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

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

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

Но настоящее решение таково:

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

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

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

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 меня просветил. При входе в Quickwatch и изучении объекта d Derived (или из контекста объекта, this) и выборе поля base в поле редактирования в верхней части Quickwatch отображается следующее приведение:

((TestProject1.Base)(d))

Это означает, что при замене базы как таковой вызов будет

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

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

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

"Oi, wait..what ? omg that DLL is like, ..doing something funny"

Я не уверен, что это странность 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.

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

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:

The binary + operator performs string concatenation when one or both operands are of type string. If an operand of string concatenation is null, an empty string is substituted. Otherwise, any non-string operand is converted to its string representation by invoking the virtual ToString method inherited from type object. If ToString returns null, an empty string is substituted.

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

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

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

Мне это очень порадовало, спасибо, ребята, MS!

Хотя это не странность или угловой случай ... а что-то действительно неожиданное из языка виртуальных машин на основе стека :)

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

Условный оператор не может привести к неявному преобразованию?

Дано:

Bool aBoolValue;

Где aBoolValue присвоено значение "Истина" или "Ложь";

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

Byte aByteValue = aBoolValue ? 1 : 0;

Но это могло бы:

Int anIntValue = aBoolValue ? 1 : 0;

Предоставленный ответ тоже довольно хорош.

Вы когда-нибудь думали, что компилятор 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]

Что делать, если у вас есть универсальный класс, в котором есть методы, которые могут быть неоднозначными в зависимости от аргументов типа? Я столкнулся с этой ситуацией недавно, когда писал двусторонний словарь. Я хотел написать симметричные методы 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..."

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

В используемом нами 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().

Следующее не работает:

if (something)
    doit();
else
    var v = 1 + 2;

Но это работает:

if (something)
    doit();
else {
    var v = 1 + 2;
}

C# Задача доступности

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

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 static bool? ToBoolean(this string s)
{
    bool result;

    if (bool.TryParse(s, out result))
        return result;
    else
        return null;
}

и этот код:

string nullStr = null;
var res = nullStr.ToBoolean();

Это не вызовет исключения, потому что это метод расширения (и на самом деле HelperClass.ToBoolean(null)), а не метод экземпляра. Это может сбивать с толку.

вот несколько моих:

1. это может быть null при вызове метода экземпляра без выброса NullReferenceException
2. значение перечисления по умолчанию не обязательно должно быть определено для перечисления

Сначала простой: перечисление NoZero { Число = 1 }

        public bool ReturnsFalse()
        {
            //The default value is not defined!
            return Enum.IsDefined(typeof (NoZero), default(NoZero));
        }

Приведенный ниже код действительно может печатать истину!

 internal sealed class Strange
{
    public void Foo()
    {
        Console.WriteLine(this == null);
    }
}

Простой фрагмент клиентского кода, который приведет к тому, что делегат void HelloDelegate (Странная полоса);

public class Program
{
    [STAThread()]
    public static void Main(string[] args)
    {
        Strange bar = null;
        var hello = new DynamicMethod("ThisIsNull",
            typeof(void), new[] { typeof(Strange) },
         typeof(Strange).Module);
        ILGenerator il = hello.GetILGenerator(256);
        il.Emit(OpCodes.Ldarg_0);
        var foo = typeof(Strange).GetMethod("Foo");
        il.Emit(OpCodes.Call, foo);
        il.Emit(OpCodes.Ret);
        var print = (HelloDelegate)hello.CreateDelegate(typeof(HelloDelegate));
        print(bar);
        Console.ReadLine();
    }
}

это действительно так для большинства языков, пока метод экземпляра при вызове не использует состояние объекта. это разыменовывается только при обращении к состоянию объекта

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

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.

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

Только что нашел сегодня приятную вещицу:

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 (материал как объект); он работает отлично, однако здесь это кажется "волшебным словом", поскольку он делает то же самое, все по-прежнему воспринимается как динамическое ...

Это довольно просто, но я все же считаю его несколько интересным. Каким будет значение x после вызова Foo?

static int x = 0;

public static void Foo()
{
    try { return; }
    finally { x = 1; }
}

static void Main() { Foo(); }

Это довольно сложно превзойти. Я столкнулся с этим, когда пытался создать реализацию 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)