0

If I look at the members of the .NET type System.Version it might be a better idea to create such a type as value type (C# struct) instead of a reference type (class).

What might be the reasons or arguments that Microsoft decided to implement that type in that way? Is it simply a kind of "bug" / mistake / inconsequence or a "feature" (in other words: "really wanted and useful"?

There are methods like Parse() and TryParse() which are typical for value types, e.g. System.Int32, System.Double or System.Guid. The properties of System.Version only store short and integer values (s. System.TimeSpan), the type itself is comparable (with operators) and as struct it might not be necessary to make it cloneable.

I do not have anything against that "status quo", it is only to satisfy my curiosity ;-)

EDIT: Added comparison to System.TimeSpan.

  • Since it is not a must for such types to be struct question is pointless. – Andrey Oct 12 '11 at 20:27
  • thats right, but i am interested to know what the reasons are for that decision –  Oct 12 '11 at 20:29
  • @Andrey - Seems like a reasonable question, seeing as `Version` looks like a perfect choice for a value type. – Oded Oct 12 '11 at 20:31
  • Why should it matter? Would it actually change any of your coding if it were a struct? – Reddog Oct 12 '11 at 20:33
  • 1
    Only one real reason I can think of: a struct can't have a default constructor. And version 0.0.0.0 is a valid version. If it were a struct then it would require an extra "version is properly initialized and valid" flag. – Hans Passant Oct 12 '11 at 20:37

3 Answers3

2

I can't say for sure, but one reason might be immutability. The properties in the Version class are all read-only. Whereas it's possible to declare readonly fields in a struct, Eric Lippert points that readonly on a struct field is a lie.

Making it a class ensures immutability.

Community
  • 1
  • 1
Jim Mischel
  • 131,090
  • 20
  • 188
  • 351
  • According to Microsoft's [guidlines](http://msdn.microsoft.com/en-us/library/ms229017.aspx), you should only define a struct if it is immutable. So it seems odd that Microsoft would follow an opposite logic, where structs should be used for mutable types, just because immutability cannot be guaranteed by the compiler. – Allon Guralnek Oct 12 '11 at 20:56
2

According to Microsoft's own guidelines, you should prefer a class to a structure when the instance is at least 16 bytes. Since System.Version stores four Int32, each consisting of four bytes for a total of 16 bytes, they followed their own advice and made it a class.

Allon Guralnek
  • 15,813
  • 6
  • 60
  • 93
  • And what is with System.DateTime? There are more than 4 properties that are System.Int32 values. –  Oct 12 '11 at 20:58
  • 2
    @Marcel `DateTime` has a single 64 bit integer field. So it's just 8 bytes total. The number of properties is irrelevant. – CodesInChaos Oct 12 '11 at 21:00
  • 1
    @MarcelJ.Kloubert: DateTime is an 8-byte struct. Way below the 16 byte cutoff. – Allon Guralnek Oct 12 '11 at 21:01
  • ah, ok. it calculates other properties, like Minutes or Seconds, from the inner ticks value... –  Oct 12 '11 at 21:05
  • 1
    I feel using 16-bytes as the watershed point is anachronistic today (2021) when x64 is the standard, and most (if not all?) processors can operate on _very_ long word-sizes efficiently thanks to AVX, etc, and as 128-bit or 256-bit memory bus widths are commonplace too - what matters is benchmarking of course, but I'm fine with writing or using struct with 4 or more `long` members, sure. Think about `ValueTuple` in C# 7.3 - where you can easily end-up with a struct that's over 64 **bytes** long without any problems. – Dai Feb 24 '21 at 23:50
1

Another point that may have been relevant in the design process is that Version is ComVisible.

As such, it makes more sense to expose it to COM as a coclass (behavior, without guarantees about internal layout) rather than as a COM struct (which specifies an in-memory layout like a C struct).

Joe
  • 122,218
  • 32
  • 205
  • 338