I see, that's an interesting take on it. Thanks. As far as my own project is concerned, it may not be interesting to do the same, as I tend to work with fractions, using floats, before feeding them to the method, so I have to cast explicitly anyway. And it'd be more efficient to avoid unneeded casts.
weeble wrote: > > I might guess this is related to the lack of byte operators. If you're > going to do any arithmetic on your bytes before you feed them into > FromArgb, you'll find you keep needing to cast back to byte, because > all the arithmetic will use int. As I see it you have these options: > > * Write the API with bytes, use slightly verbose (byte)(a+b) casts > during arithmetic. If you screw up and overflow you get weird results. > * Write the API with bytes, use very verbose checked((byte)(a+b)) > casts. If you overflow you get a runtime exception. > * Write the API with ints. No verbose casts are required. If you go > out of range then FromArgb will throw a runtime exception. > > So, if you're doing arithmetic to generate the arguments for FromArgb, > it seems slightly less painful and no more unsafe for the API to use > ints. Not a deeply compelling reason, but perhaps worth consideration. > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > -- View this message in context: http://mono.1490590.n4.nabble.com/System-Drawing-Color-FromArgb-why-int-parameters-tp3767434p3767750.html Sent from the Mono - General mailing list archive at Nabble.com. _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
