clr

I used reflection to inspect the contents of System.Int32 and found that it contains another System.Int32 . System.Int32 m_value; I don't see how that's possible. This int really is the "backing integer" of the one you have: if you box an int and use reflection to change the value of its m_value field, you effectively change the value of the integer: object testInt = 4; Console.WriteLine(testInt); // yields 4 typeof(System.Int32) .GetField("m_value", BindingFlags.NonPublic | BindingFlags.Instance) .SetValue(testInt, 5); Console.WriteLine(testInt); // yields 5 There's gotta be a rational

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. We have a bit of a battle going on in our development team over this. I would love to hear what others think about this. In the actual code? No, not unless you're going to have lots of people working on the code who are familiar with .NET but not with C#. In

I've got a problem similar to,but subtly different from, that described here (Loading assemblies and their dependencies). I have a C++ DLL for 3D rendering that is what we sell to customers. For .NET users we will have a CLR wrapper around it. The C++ DLL can be built in both 32 and 64bit versions, but I think this means we need to have two CLR wrappers since the CLR binds to a specific DLL? Say now our customer has a .NET app that can be either 32 or 64bit, and that it being a pure .NET app it leaves the CLR to work it out from a single set of assemblies. The question is how can the app code

I'm interesting in how CLR implementes the calls like this: abstract class A { public abstract void Foo<T, U, V>(); } A a = ... a.Foo<int, string, decimal>(); // <=== ? Is this call cause an some kind of hash map lookup by type parameters tokens as the keys and compiled generic method specialization (one for all reference types and the different code for all the value types) as the values? I didn't find much exact information about this, so much of this answer is based on the excellent paper on .Net generics from 2001 (even before .Net 1.0 came out!), one short note in a follow-up paper and

I know the basics on how foreach loops work in C# ( How do foreach loops work in C# ) I am wondering whether using foreach allocates memory that may cause garbage collections? (for all built in System types). For example, using Reflector on the System.Collections.Generic.List<T> class, here's the implementation of GetEnumerator: public Enumerator<T> GetEnumerator() { return new Enumerator<T>((List<T>) this); } On every usage this allocates a new Enumerator (and more garbage). Do all types do this? If so, why? (can't a single Enumerator be reused?) hangar Foreach can cause allocations, but at

Consider a process which is creating multiple application domains. Do these Application domains share same thread pool? If yes, how is it coordinated between multiple application domains? The ThreadPool is shared across all appdomains - since that means threads might end up switching between appdomains (potentially often!) there's been perf work around that: http://blogs.msdn.com/b/ericeil/archive/2009/04/23/clr-4-0-threadpool-improvements-part-1.aspx [...] In fact, we violate this “rule” already: since .NET 3.5, the CLR thread pool has maintained separate FIFO queues for each AppDomain in the

What unusual, unexpected consequences have occurred in terms of performance, memory, etc when switching from running your .NET applications under the 64 bit JIT vs. the 32 bit JIT? I'm interested in the good, but more interested in the surprisingly bad issues people have run into. I am in the process of writing a new .NET application which will be deployed in both 32bit and 64bit. There have been many questions relating to the issues with porting the application - I am unconcerned with the "gotchas" from a programming/porting standpoint . (ie: Handling native/COM interop correctly, reference

In CLR, each instance have 2 additional fields to store some data to manage object: Type Object Pointer Sync Block Index Can you explain basically what do they store inside and briefly how are they used by CLR? Thanks! The type object pointer is a pointer to a type description of the object. This is used to find out what the actual type of an object is, for example needed to do virtual calls. The sync block index is an index into a table of synchronisation blocks. Each object can have a sync block, that contains information used by Monitor.Enter and Monitor.Exit . 来源： https://stackoverflow.com

I’ve been pondering about the C# and CIL type system today and I’ve started to wonder why static classes are considered classes. There are many ways in which they are not really classes: A “normal” class can contain non-static members, a static class can’t. In this respect, a class is more similar to a struct than it is to a static class, and yet structs have a separate name. You can have a reference to an instance of a “normal” class, but not a static class (despite it being considered a “reference type”). In this respect, a class is more similar to an interface than it is to a static class,