+972 52-548-6969
What the hell?! Hex number parsing
time to read 1 min | 139 words
I have the strong feeling that I am missing something here, this fails:
try { Console.WriteLine(long.Parse("0x9f",NumberStyles.AllowHexSpecifier|NumberStyles.HexNumber, CultureInfo.InvariantCulture)); } catch (Exception e) { Console.WriteLine(e); }
Unlike the previous challenges I posted, I truly have no idea why this doesn’t work. I moved to use Convert.ToInt64, that does work. But everything I know (including the docs) tell me that this should work.
Comments
It no likey the "0x" at the beginning?
From the documentation of NumberStyle.AllowHexSpecifier
'Strings parsed using this style are not permitted to be prefixed with "0x".'
btw. NumberStyles.HexNumber includes AllowHexSpecifier already.
Oren, dropping the '0x' prefix should work, e.g:
long.Parse("9f", NumberStyles.HexNumber)
Jakob,
Thanks, I missed the not.
But What is up with _Allow_HexSpecifier, the only hex specifier that I know of is 0x
And removing that from the bit pattern doesn't help: NumberStyles.HexNumber & ~NumberStyles.AllowHexSpecifier
Uncle Festis & Demis,
I don't want to drop that.
Are you reading these docs?
msdn.microsoft.com/.../...obalization.numberstyles(VS.80).aspx
Although its contra-intuitive (wouldn't be the first time) it says:
"AllowHexSpecifier - Indicates that the numeric string represents a hexadecimal value. Valid hexadecimal values include the numeric digits 0-9 and the hexadecimal digits A-F and a-f. Hexadecimal values can be left-padded with zeros. Strings parsed using this style are not permitted to be prefixed with "0x". "
Normally in these situations I support the right behaviour by wrapping it in a 'int FromHex(this string)' extension method and move on until a better solution crosses my path.
I think AllowHexSpecifier is horribly named. But the documentation is quite clear:
The s parameter contains a number of the form:
[ws][sign]digits[ws]
Or, if style includes AllowHexSpecifier:
[ws]hexdigits[ws]
...
hexdigits
A sequence of hexadecimal digits from 0 through f, or 0 through F.
AllowHexSpecifier tells Parse to treat the number as hexadecimal. HexNumber does the same, but also allows Whitespace before/after.
Ayende,
As i remember: it isn't AllowHexSpecieir that makes the 0x prefix fail, i have never found a way to have long.Parse accept the prefix so i have used:
Convert.ToInt64("0x9f", 16);
Which is the same i asume you ended up with. But i agree with you, the naming of AllowHexSpecifier is REALLY confusing.
You do not need both, NumberStyles.AllowHexSpecifier and NumberStyles.HexNumber, values. NumberStyles.HexNumber equals to AllowLeadingWhite | AllowTrailingWhite | AllowHexSpecifier. And I agree with everyone about the bad naming of the hex specifier.
The .NET 4 page for the three-argument Int64.Parse method includes this additional tidbit following the Non-composite NumberStyles values table:
"If the NumberStyles.AllowHexSpecifier flag is used, s must be a hexadecimal value."
Source: msdn.microsoft.com/.../8b520kdx%28v=VS.100%29.aspx
I guess the "0x" is a text-editor "atrefact"? In reality, the hex number is 9F, not 0x9F.
"0x" is a hex specifier with ancestry back into the deep mists of "C" history. It's related to "0" for base 8: 27 == 033 == 0x1B
I'm not sure where it came from, but Delphi's Object Pascal language used $ to prefix int constants.
Also, the W3C uses "#" in the CSS specification.
Comment preview