C#: structs and Interface

re: C#: structs and Interface

Rick Scott — Wed, 05 Oct 2005 17:55:07 GMT

That does make perfect sense, but only after some thought. A struct implementing an interface is, to say the least, something one should approach with great caution. Perhaps a compiler warning is appropriate?

re: C#: structs and Interface

kfarmer — Wed, 05 Oct 2005 22:37:14 GMT

I recall reading somewhere that structs should not be used for mutable types. You could consider them as points in a space consisting of many values.

promote(), really, is as much a mutation as String.Trim(), and should return a different point in the employee space: one that represents the employee after promotion.

re: C#: structs and Interface

James Arendt — Thu, 06 Oct 2005 15:34:15 GMT

As kfarmer stated, the example violates the design that structs should be immutable value-types. Yes, boxing is going on here, but the code would still have the same issue if you took out boxing and simply assigned the employee object to another variable.

Employee employee = new Employee("Cool Guy", 65);
Employee employee2 = employee;
Console.WriteLine(employee2);
employee.promote();
Console.WriteLine(employee2);

Structs are value-types. They should be treated as such. That's the more important lesson to take from this example.

re: C#: structs and Interface

Andrei Ignat — Thu, 06 Oct 2005 16:43:55 GMT

With lots a feature - the language becomes more and more difficult to understand - and for NO GOOD REASON.
It was REALLY necessary that a struct can implement an interface?

re: C#: structs and Interface

James Arendt — Fri, 07 Oct 2005 16:33:48 GMT

Andrei, I would argue that the problem is not that a struct can implement an interface, but that the language designers do not enforce immutability for structs. Allowing structs to implement interfaces simplifies things by allowing developers to treat all types in their program more uniformly.

re: C#: structs and Interface

Raj — Thu, 20 Dec 2007 20:35:33 GMT

One important factor to consider is time.

To allocate an array of 1000 structs is a lot quicker (as one doesnt have to go through initializing each and every struct object). Where as if one had to allocate a 1000 class objects - that would take a lot more time.

re: C#: structs and Interface

Jeroen — Thu, 20 Mar 2008 17:05:48 GMT

As James correctly states, the problem would be the same if you used two instances of the struct. The problem is actually just the opposite: the struct will behave like a class if you cast it to the interface:

IPromotion employee = new Employee("Cool Guy", 65);

IPromotion employee2 = employee;

Console.WriteLine(employee2); // outputs 65

employee.promote();

Console.WriteLine(employee2); // outputs 66!!

The copy from employee to employee2 now only copies the *reference* to the (already boxed) instance, so both references reference the *same* value.

re: C#: structs and Interface

andarno — Tue, 15 Apr 2008 16:50:13 GMT

Great post, Abhinaba.

And thanks, Jeroen, for suggesting the workaround. It actually works in my case to rearrange the lines a bit as you have to get around my problem.

re: C#: structs and Interface

Jeroen — Wed, 11 Jun 2008 15:58:49 GMT

Andarno,

I did not quite mean it as a workaround, in fact I posted it to point out a problem area in working with interfaces and structs. If you want your thingamabob to act like a class, then you should máke it a class, and not make a struct and box it.

re: C#: structs and Interface

Scott Youngblut — Sun, 07 Dec 2008 06:50:45 GMT

The main reason to me, that you would most certainly want to make structs implement interfaces is to get the added advantage of generic parameter type constraints.

The available options you have for type constraints are struct,class,new(), (Interfaces), and (abstract classes).

To get better compile time checking you may want the method signature to look like this

public static void Add<TEnum>(TEnum augend, TEnum addend)

where TEnum : struct, IEnum

{

return augend.Add(addend);

}

Thus the caller is not allowed to pass in an integer as the most basic type constraint of just "struct" would allow.

Interfaces to the rescue?

thoughts?

ValueType | hilpers

ValueType | hilpers — Tue, 20 Jan 2009 18:18:04 GMT

PingBack from http://www.hilpers.com/305229-valuetype

Modyfing value types through an interface doesn't work with generics (Brain Puzzle?) | keyongtech

Thu, 22 Jan 2009 07:43:57 GMT

PingBack from http://www.keyongtech.com/658785-modyfing-value-types-through-an

Pop Quiz: Applied Object-Oriented Principles with C# | Necessary and Sufficient

Pop Quiz: Applied Object-Oriented Principles with C# | Necessary and Sufficient — Mon, 02 Mar 2009 15:21:47 GMT

PingBack from http://www.necessaryandsufficient.net/2009/02/pop-quiz-applied-object-oriented-principles-with-c/

re: C#: structs and Interface

Zhi Wen — Tue, 28 Apr 2009 20:20:00 GMT

nice post, I need some kind of polymorphism to store many different kind of structs in a single list and found your post. I don't need to modify the struct so interface will work perfectly for me. Thanks.

re: C#: structs and Interface

abhinaba — Tue, 28 Apr 2009 20:57:39 GMT

Zhi are you sure that your approach is not going to be a perf pitfall? Ensure that boxing doesn't become a blocker for you

re: C#: structs and Interface

Zhi Wen — Tue, 26 May 2009 21:41:24 GMT

Just did some more reading.

>>I need some kind of polymorphism to store many >>different kind of structs in a single list and found >>your post. I don't need to modify the struct so >>interface will work perfectly for me.

Actually, this is probably a bad idea. It will probably store each struct as a reference type on heap. I am not sure. This whole thing is just confusing.