Qual è il caso d'angolo più strano che hai visto in C # o .NET? [chiuso]

Colleziono alcuni astucci d'angolo e rompicapo e vorrei sempre saperne di più. La pagina copre davvero solo bit e bob del linguaggio C #, ma trovo anche interessanti le cose di .NET. Ad esempio, eccone uno che non è nella pagina, ma che trovo incredibile:

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

Mi aspetto che stampare False - dopo tutto, "new" (con un tipo di riferimento) crea sempre un nuovo oggetto, non è vero? Le specifiche per C # e CLI indicano che dovrebbe. Bene, non in questo caso particolare. Stampa True e lo ha fatto su ogni versione del framework con cui l'ho provato. (Non l'ho provato su Mono, certo ...)

Giusto per essere chiari, questo è solo un esempio del tipo di cosa che sto cercando - non ero particolarmente alla ricerca di discussioni / spiegazioni di questa stranezza. (Non è lo stesso del normale internamento di stringhe; in particolare, l'internamento di stringhe normalmente non si verifica quando viene chiamato un costruttore.) Stavo davvero chiedendo un comportamento strano simile.

Altre gemme in agguato là fuori?

Penso di averti mostrato questo prima, ma mi piace il divertimento qui - ci sono voluti alcuni debug per rintracciare! (il codice originale era ovviamente più complesso e sottile ...)

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

Quindi cosa era T ...

Risposta: qualsiasi Nullable<T>- come ad esempio int?. Tutti i metodi vengono sovrascritti, tranne GetType () che non può essere; quindi viene cast (boxed) su object (e quindi su null) per chiamare object.GetType () ... che chiama null ;-p

Aggiornamento: la trama si infittisce ... Ayende Rahien ha lanciato una sfida simile sul suo blog , ma con un 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?");
}

Ma può essere sconfitto! Usando la stessa indiretta usata da cose come il telecomando; attenzione: il seguente è puro male :

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

Con questo in atto, la new()chiamata viene reindirizzata al proxy ( MyFunnyProxyAttribute), che restituisce null. Adesso vai a lavarti gli occhi!

Arrotondamento dei banchieri.

Questo non è tanto un bug del compilatore o un malfunzionamento, ma sicuramente uno strano caso angolare ...

Il .Net Framework utilizza uno schema o un arrotondamento noto come arrotondamento del banco.

Nell'arrotondamento dei banchieri gli 0,5 numeri vengono arrotondati al numero pari più vicino, quindi

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

Ciò può comportare alcuni bug imprevisti nei calcoli finanziari basati sul più noto arrotondamento arrotondato per metà.

Questo vale anche per Visual Basic.

Cosa farà questa funzione se chiamata come Rec(0)(non sotto il debugger)?

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

Risposta:

• Su JIT a 32 bit dovrebbe risultare in StackOverflowException
• Su JIT a 64 bit dovrebbe stampare tutti i numeri su int.MaxValue

Questo perché il compilatore JIT a 64 bit applica l'ottimizzazione delle chiamate di coda , mentre il JIT a 32 bit no.

Sfortunatamente non ho a disposizione una macchina a 64 bit per verificarlo, ma il metodo soddisfa tutte le condizioni per l'ottimizzazione delle chiamate in coda. Se qualcuno ne ha uno sarei interessato a vedere se è vero.

Assegna questo!

Questo è quello che mi piace chiedere alle feste (che è probabilmente il motivo per cui non mi invitano più):

Puoi compilare il seguente pezzo di codice?

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

Un trucco semplice potrebbe essere:

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

Ma la vera soluzione è questa:

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

Quindi è risaputo che i tipi di valore (strutture) possono riassegnare la loro thisvariabile.

Pochi anni fa, quando lavoravamo al programma di lealtà, avevamo un problema con la quantità di punti assegnati ai clienti. Il problema era legato al casting / conversione del doppio in int.

Nel codice seguente:

double d = 13.6;

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

fa i1 == i2 ?

Si scopre che i1! = I2. A causa delle diverse politiche di arrotondamento nell'operatore Converti e cast, i valori effettivi sono:

i1 == 14
i2 == 13

È sempre meglio chiamare Math.Ceiling () o Math.Floor () (o Math.Round con MidpointRounding che soddisfa i nostri requisiti)

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

Avrebbero dovuto rendere 0 un numero intero anche quando c'è un sovraccarico della funzione enum.

Conoscevo la logica del team di base C # per mappare 0 su enum, ma non è così ortogonale come dovrebbe essere. Esempio da Npgsql .

Esempio di test:

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

Questo è uno dei più insoliti che abbia mai visto finora (a parte quelli ovviamente qui!):

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

Ti consente di dichiararlo ma non ha alcun reale utilizzo, dal momento che ti chiederà sempre di avvolgere qualsiasi altra classe al centro con un'altra Tartaruga.

[scherzo] Immagino che siano le tartarughe fino in fondo ... [/ scherzo]

Eccone uno che ho scoperto solo di recente ...

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

Quanto sopra sembra folle a prima vista, ma in realtà è legale. No, davvero (anche se ho perso una parte fondamentale, ma non è niente di strano come "aggiungi una classe chiamata IFoo" o "aggiungi un usingalias per indicare IFooun classe").

Vedi se riesci a capire perché, quindi: chi dice che non puoi istanziare un'interfaccia?

Quando un booleano non è né vero né falso?

Bill ha scoperto che puoi hackerare un booleano in modo che se A è vero e B è vero, (A e B) è falso.

Booleani hackerati

Arrivo un po 'tardi alla festa, ma ne ho tre quattro cinque:

1. Se esegui il polling di InvokeRequired su un controllo che non è stato caricato / mostrato, si dice falso - e ti esploderà in faccia se provi a cambiarlo da un altro thread ( la soluzione è fare riferimento a questo. Handle nel creatore del controllo).

2. Un altro che mi ha fatto inciampare è quello dato un incontro con:

   enum MyEnum
   {
       Red,
       Blue,
   }

   se calcoli MyEnum.Red.ToString () in un altro assembly e tra una volta e l'altra qualcuno ha ricompilato il tuo enum in:

   enum MyEnum
   {
       Black,
       Red,
       Blue,
   }

   in fase di esecuzione, otterrai "Nero".

3. Avevo un assemblaggio condiviso con alcune costanti utili dentro. Il mio predecessore aveva lasciato un sacco di proprietà get-only dall'aspetto brutto, pensavo che mi sarei liberato del disordine e avrei usato solo const pubblica. Sono stato più che un po 'sorpreso quando VS li ha compilati per i loro valori e non per i riferimenti.

4. Se si implementa un nuovo metodo di un'interfaccia da un altro assembly, ma si ricostruisce facendo riferimento alla versione precedente di tale assembly, si ottiene TypeLoadException (nessuna implementazione di 'NewMethod'), anche se è stata implementata (vedere qui ).

5. Dizionario <,>: "L'ordine in cui vengono restituiti gli articoli non è definito". Questo è orribile , perché a volte ti può mordere, ma funziona gli altri, e se hai semplicemente supposto ciecamente che il Dizionario suonerà bene ("perché non dovresti farlo? Pensavo, Elenco lo fa"), devi davvero avere il naso dentro prima di iniziare finalmente a mettere in discussione il tuo presupposto.

VB.NET, nullables e l'operatore ternario:

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

Questo ha richiesto del tempo per il debug, poiché mi aspettavo idi contenereNothing .

Cosa contiene veramente? 0.

Ciò è sorprendente ma in realtà comportamento "corretto": Nothingin VB.NET non è esattamente lo stesso nulldi CLR: Nothingpuò significare nullo default(T)per un tipo di valore T, a seconda del contesto. Nel caso di cui sopra, Ifdeduce Integercome tipo comune Nothinge 5, quindi, in questo caso, Nothingmezzi 0.

Ho trovato un secondo caso davvero strano d'angolo che batte il mio primo da un colpo lungo.

Il metodo String.Equals (String, String, StringComparison) non è in realtà privo di effetti collaterali.

Stavo lavorando su un blocco di codice che aveva questo su una riga da solo nella parte superiore di alcune funzioni:

stringvariable1.Equals(stringvariable2, StringComparison.InvariantCultureIgnoreCase);

La rimozione di quella linea porta a uno overflow dello stack da qualche altra parte nel programma.

Si è scoperto che il codice stava installando un gestore per quello che era essenzialmente un evento BeforeAssemblyLoad e che cercava di fare

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

Ormai non avrei dovuto dirtelo. L'uso di una cultura che non è mai stata utilizzata in precedenza in un confronto di stringhe provoca un caricamento dell'assembly. InvariantCulture non fa eccezione.

Ecco un esempio di come è possibile creare una struttura che causa il messaggio di errore "Tentativo di leggere o scrivere memoria protetta. Questa è spesso un'indicazione che l'altra memoria è corrotta". La differenza tra successo e fallimento è molto sottile.

Il seguente test unitario dimostra il problema.

Vedi se riesci a capire cosa è andato storto.

    [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 # supporta le conversioni tra matrici ed elenchi purché le matrici non siano multidimensionali e vi sia una relazione di ereditarietà tra i tipi e i tipi sono tipi di riferimento

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" };

Si noti che questo non funziona:

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

Questo è il più strano che ho incontrato per caso:

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

Usato come segue:

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

Lancerà a NullReferenceException. Si scopre che le aggiunte multiple sono compilate dal compilatore C # per una chiamata a String.Concat(object[]). Prima di .NET 4, c'è un bug proprio in quel sovraccarico di Concat in cui l'oggetto è controllato per null, ma non il risultato di 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;

Questo è un bug di ECMA-334 §14.7.4:

L'operatore binario + esegue la concatenazione di stringhe quando uno o entrambi gli operandi sono di tipo string. Se un operando di concatenazione di stringhe è null, viene sostituita una stringa vuota. Altrimenti, qualsiasi operando senza stringa viene convertito nella sua rappresentazione di stringa richiamando il ToStringmetodo virtuale ereditato dal tipo object. Se ToStringrestituisce null, viene sostituita una stringa vuota.

Interessante - quando ho visto per la prima volta che ho pensato che fosse qualcosa che il compilatore C # stava verificando, ma anche se si emette direttamente l'IL per rimuovere qualsiasi possibilità di interferenza, ciò accade ancora, il che significa che è davvero il newobjcodice operativo che sta facendo il controllo.

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

Ciò equivale anche a trueverificare se string.Emptyciò significa che questo codice operativo deve avere un comportamento speciale per le stringhe vuote interne.

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

L'output è "Tentativo di leggere la memoria protetta. Questa è un'indicazione che l'altra memoria è danneggiata."

PropertyInfo.SetValue () può assegnare ints a enum, ints a null nulla, enum a enumerabili nulla, ma non in en nullable.

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

Descrizione completa qui

Cosa succede se si dispone di una classe generica che ha metodi che potrebbero essere resi ambigui a seconda degli argomenti del tipo? Mi sono imbattuto in questa situazione di recente scrivendo un dizionario a due vie. Volevo scrivere Get()metodi simmetrici che avrebbero restituito l'opposto di qualunque argomento fosse passato. Qualcosa come questo:

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

Va tutto bene se crei un'istanza in cui T1e di T2tipi diversi:

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

Ma se T1e T2sono uguali (e probabilmente se uno fosse una sottoclasse di un altro), è un errore del compilatore:

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

È interessante notare che tutti gli altri metodi nel secondo caso sono ancora utilizzabili; sono solo le chiamate al metodo ora ambiguo che causa un errore del compilatore. Caso interessante, anche se un po 'improbabile e oscuro.

Puzzle di accessibilità C #

La seguente classe derivata sta accedendo a un campo privato dalla sua classe base e il compilatore guarda silenziosamente dall'altra parte:

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

Il campo è infatti privato:

private int m_basePrivateField = 0;

Vuoi indovinare come possiamo compilare questo codice?

.

.

.

.

.

.

.

Risposta

Il trucco è dichiarare Derivedcome una classe interna di Base:

public class Base
{
    private int m_basePrivateField = 0;

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

Alle classi interne viene dato pieno accesso ai membri della classe esterna. In questo caso, anche la classe interna deriva dalla classe esterna. Questo ci consente di "rompere" l'incapsulamento dei membri privati.

Ho appena trovato una cosa carina oggi:

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

Questo genera errore di compilazione.

La chiamata al metodo "Inizializza" deve essere inviata in modo dinamico, ma non può essere perché fa parte di un'espressione di accesso di base. Prendi in considerazione la possibilità di lanciare argomenti dinamici o eliminare l'accesso di base.

Se scrivo base.Initialize (roba come oggetto); funziona perfettamente, tuttavia questa sembra essere una "parola magica" qui, dal momento che fa esattamente lo stesso, tutto è ancora ricevuto come dinamico ...

In un'API che stiamo utilizzando, i metodi che restituiscono un oggetto dominio potrebbero restituire uno speciale "oggetto null". Nell'implementazione di questo, l'operatore di confronto e il Equals()metodo vengono sostituiti per essere restituiti truese confrontati connull .

Quindi un utente di questa API potrebbe avere un codice come questo:

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

o forse un po 'più prolisso, in questo modo:

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

dove GetDefault()è un metodo che restituisce un valore predefinito che vogliamo usare al posto di null. La sorpresa mi ha colpito quando stavo usando ReSharper e seguendo la sua raccomandazione di riscrivere uno di questi a quanto segue:

return test ?? GetDefault();

Se l'oggetto test è un oggetto null restituito dall'API invece che corretto null, il comportamento del codice è ora cambiato, poiché l'operatore di coalescenza null verifica effettivamente null, non in esecuzione operator=o Equals().

Considera questo strano caso:

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

Se Basee Derivedsono dichiarati nello stesso assembly, il compilatore renderà Base::Methodvirtuale e sigillato (nel CIL), anche seBase non implementa l'interfaccia.

Se Basee si Derivedtrovano in assiemi diversi, durante la compilazione Deriveddell'assembly, il compilatore non modificherà l'altro assembly, quindi introdurrà un membro Derivedche sarà un'implementazione esplicita in MyInterface::Methodquanto delegherà la chiamata aBase::Method .

Il compilatore deve farlo per supportare l'invio polimorfico per quanto riguarda l'interfaccia, ovvero deve rendere virtuale quel metodo.

Quanto segue potrebbe essere una conoscenza generale che mi mancava semplicemente, ma eh. Qualche tempo fa, abbiamo avuto un bug case che includeva proprietà virtuali. Estrarre un po 'il contesto, considerare il codice seguente e applicare il punto di interruzione all'area specificata:

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 { } }
}

Mentre si è nel Derivedcontesto dell'oggetto, è possibile ottenere lo stesso comportamento quando si aggiunge base.Propertycome orologio o si digitabase.Property nel quickwatch.

Mi ci è voluto un po 'di tempo per capire cosa stesse succedendo. Alla fine sono stato illuminato dal Quickwatch. Quando si accede a Quickwatch ed esplora l' Derivedoggetto d (o dal contesto dell'oggetto this) e si seleziona il campo base, il campo di modifica nella parte superiore di Quickwatch visualizza il seguente cast:

((TestProject1.Base)(d))

Ciò significa che se la base viene sostituita come tale, la chiamata sarebbe

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

per gli orologi, Quickwatch e le descrizioni dei comandi del mouse per il debug, e avrebbe quindi senso che venga visualizzato "AWESOME"invece di "BASE_AWESOME"considerare il polimorfismo. Non sono ancora sicuro del perché lo trasformerebbe in un cast, un'ipotesi è che callpotrebbe non essere disponibile dal contesto di quei moduli, e solo callvirt.

Ad ogni modo, ciò ovviamente non altera nulla in termini di funzionalità, Derived.BasePropertytornerà comunque davvero "BASE_AWESOME", e quindi questa non era la radice del nostro bug al lavoro, semplicemente un componente confuso. Tuttavia, ho trovato interessante il modo in cui potrebbe fuorviare gli sviluppatori che non sarebbero a conoscenza di questo fatto durante le loro sessioni di debug, specialmente se Basenon sono esposti nel progetto ma piuttosto indicati come una DLL di terze parti, risultando in Dev che dicono solo:

"Oi, aspetta ... cosa? Omg che DLL è come ... facendo qualcosa di divertente"

Questo è piuttosto difficile da superare. Mi ci sono imbattuto mentre stavo cercando di realizzare un'implementazione di RealProxy che supporti veramente Begin / EndInvoke (grazie a MS per aver reso impossibile fare questo senza orribili hack). Questo esempio è fondamentalmente un bug nel CLR, il percorso del codice non gestito per BeginInvoke non convalida che il messaggio di ritorno da RealProxy.PrivateInvoke (e il mio override Invoke) restituisca un'istanza di un IAsyncResult. Una volta restituito, il CLR viene incredibilmente confuso e perde qualsiasi idea di cosa stia succedendo, come dimostrato dai test in fondo.

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.
        }
    }
}

Produzione:

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) 

Non sono sicuro che diresti che questa è una stranezza di Windows Vista / 7 o una stranezza .Net ma mi ha fatto grattare la testa per un po '.

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."

In Windows Vista / 7 il file verrà effettivamente scritto C:\Users\<username>\Virtual Store\Program Files\my folder\test.txt

Hai mai pensato che il compilatore C # potesse generare CIL non valido? Esegui questo e otterrai un 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));
  }
}

Non so come vada a buon fine nel compilatore C # 4.0.

EDIT : questo è l'output dal mio sistema:

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'è qualcosa di veramente eccitante in C #, il modo in cui gestisce le chiusure.

Invece di copiare i valori della variabile dello stack nella variabile free di chiusura, fa quella magia del preprocessore che avvolge tutte le occorrenze della variabile in un oggetto e quindi lo sposta dallo stack - direttamente nell'heap! :)

Immagino che questo renda il linguaggio C # ancora più funzionalmente completo (o lambda-complete huh)) rispetto allo stesso ML (che usa lo stack value che copia AFAIK). F # ha anche quella funzione, come fa C #.

Questo mi fa molto piacere, grazie ragazzi MS!

Non è un caso strano o angolare però ... ma qualcosa di veramente inaspettato da un linguaggio VM basato su stack :)

Da una domanda che non ho posto molto tempo fa:

L'operatore condizionale non può eseguire il cast implicitamente?

Dato:

Bool aBoolValue;

Dove aBoolValueè assegnato Vero o Falso;

Non verrà compilato quanto segue:

Byte aByteValue = aBoolValue ? 1 : 0;

Ma questo avrebbe:

Int anIntValue = aBoolValue ? 1 : 0;

Anche la risposta fornita è abbastanza buona.

Lo scoping in c # a volte è davvero bizzarro. Lascia che ti faccia un esempio:

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

OleDbCommand command = SQLServer.CreateCommand();

Questo non riesce a compilare, perché il comando è redeclared? Ci sono alcune ipotesi interessanti sul perché funzioni in questo modo su StackOverflow e nel mio blog .