The third and most internal loop iterates through a list of
NumberStyles
and calls the corresponding
ParseNumber
version. Initially, it accounted for all the possible values (i.e.,
NumberStyles enum
members) with no further modification; for example: calling
Old.ParseNumber
(or
New.ParseNumber
) with the inputs
"5.5"
&
NumberStyles.AllowDecimalPoint
,
"5.5"
&
NumberStyles.AllowParentheses
and so on. Later, I started to account for special cases, where the given
NumberStyles
value is associated with certain modifications in the input string; for example:
"5"
&
NumberStyles.AllowDecimalPoint
, but then
"(5)"
&
NumberStyles.AllowParentheses
. Note that
ParseNumber
is used under many different input conditions, like the
Parse
/
TryParse
methods of all the numeric types (e.g.,
decimal
,
int
,
double
, etc.), and that not all the
NumberStyles
values are always effective; for example:
NumberStyles.AllowHexSpecifier
and
NumberStyles.HexNumber
only make sense*** with integer types (e.g.,
int
or
long
). On the other hand and after confirming the similarities among different types, the performance tests were completely focused on
decimal
; the remaining main numerical types were exclusively considered during the final validation via
CoreRun.exe (i.e., by using
ParseNumber_Validation.exe). Nevertheless, I did enough tests to conclude that the input conditions don't have a relevant effect on the observed new-old performance differences; anyone is welcome to confirm this point by taking advantage of the easily-modifiable structure of all the involved codes.
*** NOTE: despite not being supported, the situation is valid in appearance (i.e., Visual Studio doesn't show any kind of warning or error for these erroneous inputs). For example:
decimal
cannot deal with hexadecimal inputs and, consequently,
decimal.Parse("FFFFFFFF", NumberStyles.AllowHexSpecifier)
triggers an error; what doesn't happen with supported alternatives, like
long.Parse("FFFFFFFF", NumberStyles.AllowHexSpecifier)
. These situations represent, in my opinion, an additional reason for creating the new
decimal.TryParseExact
(I am planning to work on it during the next months and, most likely, make it part of the new Project 9); even for redefining the parsing actions of all the numeric types (at least, the
NumberStyles
usage).