Updated C# and .NET docs supplement (markdown)

James Groom 2023-02-08 04:51:50 +10:00
parent a0ee189bcb
commit ebf1a709c7
1 changed files with 3 additions and 3 deletions

@ -13,7 +13,7 @@ see [feature matrix](https://github.com/TASEmulators/BizHawk/wiki/Available-C%23
## `String.GetHashCode` stability ## `String.GetHashCode` stability
The `GetHashCode` implementation for strings does not reflect the string's contents, and as such, is not stable between program instances. The `GetHashCode` implementation for strings does not reflect the string's contents, and as such, the hash not stable between program instances.
## `System.Drawing.SystemIcons` rendered ## `System.Drawing.SystemIcons` rendered
@ -22,13 +22,13 @@ The `GetHashCode` implementation for strings does not reflect the string's conte
![SystemIcons_Win10](https://user-images.githubusercontent.com/13409956/217321727-b3527c87-3ad9-44bb-8276-01afde65a939.png) ![SystemIcons_Win10](https://user-images.githubusercontent.com/13409956/217321727-b3527c87-3ad9-44bb-8276-01afde65a939.png)
![SystemIcons_Mono](https://user-images.githubusercontent.com/13409956/217311223-0d6acd76-203b-4694-9f45-4e4b8acc184b.png) ![SystemIcons_Mono](https://user-images.githubusercontent.com/13409956/217311223-0d6acd76-203b-4694-9f45-4e4b8acc184b.png)
Notice also the default window icon (`Form.Icon`): on Windows, it's a distinct icon; on Mono, it resembles `SystemIcon.Application` (not shown in the screenshot). Notice also the default window icon (`Form.Icon`): on Windows, it's a distinct icon; on Mono, it resembles `SystemIcon.Application` (not shown in the screenshot). From 2.9, EmuHawk overrides the default.
## Type casting ## Type casting
There are two types of casts in C#: the C-style `(T) o` throws if the object is not of the desired type, whereas `o as T` evaluates to `null` if it's not of the desired type. There's no '?' in this `null`-producing operator (this is probably only confusing if you use Kotlin). There are two types of casts in C#: the C-style `(T) o` throws if the object is not of the desired type, whereas `o as T` evaluates to `null` if it's not of the desired type. There's no '?' in this `null`-producing operator (this is probably only confusing if you use Kotlin).
If an object being the wrong type is *exceptional*, the method can't handle it gracefully, then throw an *exception* straight away. Having it reported as an NRE when there's no `null` in sight just delays debugging the problem. If an object being the wrong type is *exceptional*—the method can't handle it gracefully—then throw an *exception* straight away. Having it reported as an NRE when there's no `null` in sight just delays debugging the problem.
## Type constraints (`where` clauses) ## Type constraints (`where` clauses)