Are .NET structs copied-on-write?

.NET structs are value types, meaning that if function A creates a struct and calls function B, which tries to change the struct, B will get a new copy of the struct, so the changes won't apply to A's struct.

Structs can be much bigger than the CLR's other value types. Lets say that one function creates a large struct, calls another and passes the struct to the function. This goes on for 10 levels, but all functions just need to read开发者_如何学JAVA data from the struct, and do not change any of the fields . If a new copy of the struct is indeed created in each function call, the above scenario will result allocating many unneeded structs.

C language users can avoid this by passing a pointer instead of the struct itself, and if the inner functions should not change that data in the struct, the const keyword can be used.

However, C# has references instead of pointers, and there is no such thing as "const ref".

My question is: Is .NET optimized in such way that it knows to copy a struct only when a function tries to change the fields inside, or that new copy is always created once a struct is passed to another function?

the above scenario will result allocating many unneeded structs

Thinking about this in terms of "allocate" is pretty drastic mismatch with what really happens. Struct values are passed through CPU registers, the stack if they get large or there are too many arguments to pass. This is dirt cheap, no runtime support method gets called and there is no notion of "freeing" the allocation.

This otherwise works almost identically as in native C/C++ code, with the caveat that the x86 JIT compiler tends to generate better code since struct passing always goes through the stack in the native calling conventions (other than __fastcall). Pointers are supported as well, just like in C, you just declare the argument with the ref keyword. Minus the const keyword, you'll have to live without that one.

The cost of passing structs goes up drastically when the struct is larger than 16 bytes. It no longer gets pushed on the stack, the jitter generates code to pass a pointer to a copy of the value on the local stack frame. In effect the value gets copied twice, at the call site as well as the callee. Which is why the .NET framework guide recommends switching to a class when the struct gets too large. Passing by ref however works too to avoid the copying, with the caveat that all member accesses are indirect. Just like in C.

Don't hesitate to use a class instead of struct, the garbage collector is very efficient.

You can pass a value type by reference:

public void SomeMethod(ref SomeValueType someValue)

But to answer your specific question, no I don't believe there are any such optimizations, nor would I find them desirable. I'd much rather have consistent behavior. If you're using massive value types and passing them around willy-nilly, you're doing it wrong.

If your struct contains properties, as opposed to fields, then you can declare a readonly interface to the struct and pass a reference to that instead.

public interface IMyReadOnlyStruct
{
   int A { get; }
}

public struct MyStruct: IMyReadOnlyStruct
{
   public int A { get; set; }
}

public void MyReadOnlyMethod(ref IMyReadOnlyStruct a)
{
    ....
}

This is also how I would pass a readonly reference to an object around. Because you can do this C# doesn't need to support const. Using interfaces you can have a const reference, but also a reference where only any given subset of the objects properties are accessible.

Unfortunately if your struct contains fields then you can't do this. But in that case I would change the struct anyway.

To answer the question; yes structs are copied whenever needed: writing to a field/variable, or passing into a method. This is not optimised away and doesn't need to be.

If it is a struct, it should be immutable - then the issue of another method changing the fields is moot: it shouldnt be changing them, and they should be readonly.

Re the issue of being over-sized; if it is over-size it shouldn't be a struct; it should be a class - but if it represents a discreet value you may also want to keep it immutable even in class form.

Another answer to both problems is to pass it "ref" to methods, or to encapsulate it as a field, not property on a class, but IMO either of these usually means they are using a struct incorrectly in the first place.

The real change I would make here is to assess whether this really is a "value". Values never change; structs therefore shouldn't need to mutate. If you can't say this about your type, it probably shouldn't be a struct.