ShuriZma
/
BizHawk
mirror of https://github.com/TASEmulators/BizHawk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
C#-and-.NET-docs-supplement.md

@ -13,7 +13,7 @@ see [feature matrix](https://github.com/TASEmulators/BizHawk/wiki/Available-C%23
## `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
@ -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_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
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)