Comment On Classic WTF: To the Hexth Degree

I just cannot unsee it!

Duh. Not only is counting done from 1 to 4, it also starts on the wrong end of the nibble. Not bad. :)

Oh sweet Mother of God!

My eyes!

public static string ConvertToHexadecimal(string input)

{

    byte[] bytes = Encoding.ASCII.GetBytes(input);

    StringBuilder s = new StringBuilder();

    for (int n = 0; n < bytes.Length; n++) {

        s.Append(String.Format("{0,2:x}", bytes[n]).Replace(" ", "0"));

    }

    return s.ToString();

}

Well that would be my implementation. Probably a better /shorter way somewhere.

This guy was obviously paid by the line. Laugh all you want, but he's now sipping martinis on his private 100m yacht.

Dear sir, we are interested in your implementation of this function. We find it to be sufficiently complex for use in our enterprise software, as we find that all functions under 1000 lines are inadequate and poor. Please expand on your comments somewhat, and we would be willing to pay the going market rate for this product ($200/LOC).

Yours sincerely,

PHB

hello freind

i am try ot hex some String for collage. but you Jaava is not work. ther is nto complier erorr.

how to mak wrok?

emial of list plz?

Sunday Ironfoot:

Well that would be my implementation. Probably a better /shorter way somewhere.

What about Integer.toHexString() ?

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

But at least *their* version is easier to extend if hexadecimal suddenly gets a 17th character...

No fewer than!

So *THAT'S* why my Vista runs so slow...

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

Bisqwit:

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

I don't know much C but I love this solution :)

var idx = 0001 * (bit1 ? 1 : 0)

        + 0010 * (bit2 ? 1 : 0)

        + 0100 * (bit3 ? 1 : 0)

        + 01000 * (bit4 ? 1 : 0);



switch(idx){

case 0:

   return "0";

case 1:

   return "1";

case 2:

   return "2";

//...

case 16:

   return "F";

}

Sunday Ironfoot:

public static string ConvertToHexadecimal(string input)

{

    byte[] bytes = Encoding.ASCII.GetBytes(input);

    StringBuilder s = new StringBuilder();

    for (int n = 0; n < bytes.Length; n++) {

        s.Append(String.Format("{0,2:x}", bytes[n]).Replace(" ", "0"));

    }

    return s.ToString();

}

Well that would be my implementation. Probably a better /shorter way somewhere.

public static string ConvertToHexadecimal(string input)

{

    return ConvertToHexadecimal(Encoding.Default.GetBytes(input));

}

public static string ConvertToHexadecimal(byte[] input)

{

    return ConvertToHexadecimal(input, 0, input.Length);

}

public static string ConvertToHexadecimal(byte[] input, int index, int length)

{

    const string hex = "0123456789abcdef";

    char[] buffer = new char[length * 2];

    for (int n = index; n < length; n++) {

        buffer[2*n] = hex[input[n] >> 4];

        buffer[2*n+1] = hex[input[n] & 0x0f];

    }

    return new string(buffer);

}

A slightly better version would be one that works with Streams and TextWriters.

Sunday Ironfoot:

[..]
Well that would be my implementation. Probably a better /shorter way somewhere.

In Java it can indeed be done in 1 line:

public static String toHex(byte[] input) {

  return new BigInteger(input).toString(16); 

}

We had a related wtf here a couple of weeks ago.
On my current project, we use BigInteger to do this conversion:

new BigInteger(1, data).toString(16);

which should be fine. Except that our byte-arrays actually
represent sha1 hashcodes. We spent a long time scratching our hands over strange checksum mismatches in the code, until it
finally came to our attention that the problem only arose when
the checksum had leading 0's .

Wow, I've written it more concisely in XSL (version 1)

Zecc:

var idx = 0001 * (bit1 ? 1 : 0)

        + 0010 * (bit2 ? 1 : 0)

        + 0100 * (bit3 ? 1 : 0)

        + 01000 * (bit4 ? 1 : 0);

That would be octal.

Python:

'data as bytestring'.encode('hex')

In C:

what about a good old sprintf?

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

In C, such should always be written as (bit1*8+bit2*4+bit3*2+bit4)["0123456789ABCDEF"]

Marcelk:

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

In C, such should always be written as (bit1*8+bit2*4+bit3*2+bit4)["0123456789ABCDEF"]

That's just fugly.

Stavros:

No fewer than!

Wanna bet‽

Linguists say no! Or actually, they say "prescriptivist poppycock", but it's much the same thing.

But at least *their* version is easier to extend if hexadecimal suddenly gets a 17th character...

Exactly. I find especially enlightened this part of the code:

public static final int NUMBER_OF_HEXADECIMAL_CHARACTERS_PER_BYTE = 2;

to ensure compatibility, should the Universe reboot and the laws of mathematics be modified, in case the number of hex numbers per byte changes.

D0R:

Exactly. I find especially enlightened this part of the code:

public static final int NUMBER_OF_HEXADECIMAL_CHARACTERS_PER_BYTE = 2;

to ensure compatibility, should the Universe reboot and the laws of mathematics be modified, in case the number of hex numbers per byte changes.

Pah, who says that the numbers of bits in a byte will be an integer value after the reboot. Put everything in strings and decode it as required.

D0R:

But at least *their* version is easier to extend if hexadecimal suddenly gets a 17th character...

Exactly. I find especially enlightened this part of the code:

public static final int NUMBER_OF_HEXADECIMAL_CHARACTERS_PER_BYTE = 2;

to ensure compatibility, should the Universe reboot and the laws of mathematics be modified, in case the number of hex numbers per byte changes.

Actually, in C a byte does not necessarily have 8 bits. There is nothing in the least unusual about needing more than 2 hex digits to represent a byte.

In Java, a byte does have 8 bits.

srednitsa:

In Java, a byte does have 8 bits.

Yes. It would thus require a change of the Java standard - not quite as epochal as a "Universe reboot", wouldn't you agree?

Bisqwit:

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

Like it all you want, but all it'll get you is a core dump ;)

That's so obviously wrong! The arrays are never used!

A proper implementation should be:
public static final object[] F_BITS = new object[]{true, true, true, true, F, F_LOWER};

and then they can do the check by simply doing:
if (bit1 == F_BITS[FIRST_BIT_OFFSET] && bit2 == F_BITS[SECOND_BIT_OFFSET] && bit3 == F_BITS[THIRD_BIT_OFFSET] && bit4 == F_BITS[FOURTH_BIT_OFFSET])
return F_BITS[LOWERCASE_OFFSET];

(They need to add constants for LOWERCASE_OFFSET and UPPERCASE_OFFSET and use the same number constant for both from 0 to 9).

for each letter in the array. There, much better.

Dalden:

Sunday Ironfoot:

Well that would be my implementation. Probably a better /shorter way somewhere.

What about Integer.toHexString() ?

or
hex = sprintf(i, '%x'); // not sure on the java syntax

Bisqwit:

Well, I dunno much about java, but C...
*("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
should work...

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

Shift and OR operations are faster than multiplication. I'd be curious to compare the assembly output from an optimizing compiler for each and see which is more efficient.

ambrosen:

Stavros:

No fewer than!

Wanna bet‽

Linguists say no! Or actually, they say "prescriptivist poppycock", but it's much the same thing.

Yakka foob mog, grub pubbawup zink watoom gazork. Chumble spuzz.

And if you don't like those words, you're being prescriptivist. I think they're perfectly valid.

Perl code examples plz? ;-)

a (good) optimizing compiler will most definitely transform the "bit1*8" to "bit1<<3" as long as bit1 .. bitn are integer/byte/... types

btw.
see also this (i love this example - code like that has driven me nuts on "reengineering" ) http://www.nynaeve.net/?p=115

Leon:

ambrosen:

Stavros:

No fewer than!

Wanna bet‽

Linguists say no! Or actually, they say "prescriptivist poppycock", but it's much the same thing.

Yakka foob mog, grub pubbawup zink watoom gazork. Chumble spuzz.

And if you don't like those words, you're being prescriptivist. I think they're perfectly valid.

Indeed, quite cromulent.

brazzy:

Actually, in C a byte does not necessarily have 8 bits. There is nothing in the least unusual about needing more than 2 hex digits to represent a byte.

Actually, in C there is no "byte" data type

They use not only too many lines to do a simple things that could be done in one line, but they have way too many comments, also!

Roman:

Perl code examples plz? ;-)

sprintf("%x",$_);

?

frustrati:

brazzy:

Actually, in C a byte does not necessarily have 8 bits. There is nothing in the least unusual about needing more than 2 hex digits to represent a byte.

Actually, in C there is no "byte" data type

Actually, brazzy did not write anything about data types. TRWTF: Trying to be a smart butt + lacking knowledge. Hint: Read the standard before posting nonsense about C.

csrster:

We had a related wtf here a couple of weeks ago.
On my current project, we use BigInteger to do this conversion:

new BigInteger(1, data).toString(16);

which should be fine. Except that our byte-arrays actually
represent sha1 hashcodes. We spent a long time scratching our hands over strange checksum mismatches in the code, until it
finally came to our attention that the problem only arose when
the checksum had leading 0's .

Working for Nintendo?

One day, after a code review by one of our 'senior' developers this little beauty showed up...

#define NUMBER_OF_BITS_IN_BYTE 8

The justification was... that the byte might change.... and no 'magic' numbers should appear in the code...

Not necessarily, depends on the platform. Some platforms only have 1-bit shift operations, and on those platforms, bit1<<3 would need a loop to be implemented, which may be slower than a multiplication.

Anyway, good optimizers always decide, on a case-per-case basis, which one is faster, so programmers should just stick to what is more readable (do you actually want to multiply values, or just shift bits?).

Never try to do the optimizer's work manually!

Manos:

One day, after a code review by one of our 'senior' developers this little beauty showed up...

#define NUMBER_OF_BITS_IN_BYTE 8

The justification was... that the byte might change.... and no 'magic' numbers should appear in the code...

Actually I can understand this. Not because the byte might change but rather to document the code. Why make the next guy who has to maintain your code have to figure out what the number 8 represents when you can make it glaringly obvious this way?

I'm sure the code making use of this depends on a certain bug in this "algorithm", so you won't be able to exchange it.

Manos:

One day, after a code review by one of our 'senior' developers this little beauty showed up...

#define NUMBER_OF_BITS_IN_BYTE 8

The justification was... that the byte might change....

You might want to read up on what a "byte" is and is not:
http://en.wikipedia.org/wiki/Byte
The only WTF in that is that he didn't use CHAR_BIT in limits.h, which has exactly that content for exactly that reason.

From: Management
To: Code Monkey
Date: Friday, August 29, 2008 04:15 pm
Subject: Labor Day Holiday

Mr. Mankey,

I have received your request for time off on Monday. This will be no problem as long as you finish the hexadecimal conversion method assigned to you earlier this month. It is looking good so far, but the client has requested a small piece of additional functionality. Please upgrade your method to allow balanced ternary input and provide the option for base 42 output. This should be an easy fix for an experienced programmer. Remember, the new method must be released to production by the end of the day.

Regards,

P. H. Boss

Marcelk:

I like "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4] slightly better.

In C, such should always be written as
(bit1*8+bit2*4+bit3*2+bit4)["0123456789ABCDEF"]

This one is cleaner:
*(bit1*8 + bit2*4 + bit3*2 + bit4 + "0123456789ABCDEF")