On 17-Mar-2008, David Bateman wrote: | > What about the attached. Is this is accepted in to the octave-core could | > you adapt your code to use num2hex and hex2num instead? We should then | > think about getting the code on to octave-forge. | | Here is another version that adds a couple of tests.
Thanks, I applied this patch. | + num <<= 4; | + if (ch >= 'a') | + num += static_cast<uint64_t> (ch - 'a' + 10); | + else if (ch >= 'A') | + num += static_cast<uint64_t> (ch - 'A' + 10); | + else | + num += static_cast<uint64_t> (ch - '0'); This works for ASCII but would fail for EBCDIC (at least the version shown here: http://en.wikipedia.org/wiki/EBCDIC) since 'A' has a character code greater than 'a'. I realize that this is probably does not matter for any system that Octave currently runs on, but is there another good way to do this that does not rely on ASCII ordering other than switch (ch) { case 'f': case 'F': num += 15; break; case 'e': case 'E': num += 14; break; [...] case '0': break; default: error ("hex2num: invalid character found in string"); break; } ? I'm not quite paranoid enough to change this. I'm more curious to know if anyone knows of another (efficient) trick that avoids the possiblity of trouble due to a strange character encoding. | + unsigned char ch = | + static_cast<char> (num >> ((15 - j) * 4) & 0xF); | + if (ch >= 10) | + ch += 'a' - 10; | + else | + ch += '0'; I guess this would work as long as 0-9 and a-f are sequential in the character set. Even EBCDIC (all versions?) had that, though the full A-Z and a-z were not sequential. jwe ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
