views:

171

answers:

5

Say I have a string like:

string hex = "48656c6c6f";

Where every two characters correspond to the hex representation of their ASCII, value, eg:

0x48 0x65 0x6c 0x6c 0x6f = "Hello"

So how can I get "hello" from "48656c6c6f" without having to create a lookup ASCII table? atoi() obviously won't work here.

+1  A: 

strtol should do the job if you add 0x to each hex digit pair.

schnaader
You don't need the 0x, you just need to pass 16 as the third argument. But strtol is massive overkill for this job...
Zack
Ah, I see. Yeah, only wanted to give a quick response, this is of course not the best solution (especially for C++).
schnaader
+5  A: 

Or, if you want to do this the "C++ way" you can use stringstreams (#include <sstream>) and iomanip (#include <iomanip>)

http://www.cplusplus.com/reference/iostream/stringstream/ and http://www.cplusplus.com/reference/iostream/manipulators/

for reference.

Matt Kane
+1 [ ](http://www.google.com)
NullUserException
+5  A: 
int len = hex.length();
std::string newString;
for(int i=0; i< len; i+=2)
{
    string byte = hex.substr(i,2);
    char chr = (char) (int)strtol(byte.c_str(), null, 16);
    newString.push_back(chr);
}
James Curran
I'd go with this answer, as it wont depend on integer lengths
Xzhsh
Storing a length in an `int`. Now why would you do that?
sbi
@sbi: If I didn't, it would call string::length() every time through the loop. Since I know it's going to remain constant, no need going through the extra work. (Unless you are questioning my choice of int over say long -- because I couldn't see this as being practical on a string longer than that which would fit into an int length)
James Curran
@James Is `string::length()` O(1)?
NullUserException
@James: The length of a `std::string` is to be stored in `std::string::size_type`. The C lib uses `std::size_t` for this.
sbi
@NullUSerException: I'm not sure if that's a requirement or not, but regardless, O(1) is not O(0).
James Curran
This is *ten times* slower than it needs to be (see my answer).
Zack
I agree with sbi: use size_t for this. Your IDE/compiler should flag this as a warning anyway.
John Gaughan
+3  A: 

Hex digits are very easy to convert to binary:

// C++98 guarantees that '0', '1', ... '9' are consecutive.
// It only guarantees that 'a' ... 'f' and 'A' ... 'F' are
// in increasing order, but the only two alternative encodings
// of the basic source character set that are still used by
// anyone today (ASCII and EBCDIC) make them consecutive.
unsigned char hexval(unsigned char c)
{
    if ('0' <= c && c <= '9')
        return c - '0';
    else if ('a' <= c && c <= 'f')
        return c - 'a' + 10;
    else if ('A' <= c && c <= 'F')
        return c - 'A' + 10;
    else abort();
}

So to do the whole string looks something like this:

void hex2ascii(const string& in, string& out)
{
    out.clear();
    out.reserve(in.length() / 2);
    for (string::const_iterator p = in.begin(); p != in.end(); p++)
    {
       unsigned char c = hexval(*p);
       p++;
       if (p == in.end()) break; // incomplete last digit - should report error
       c = c << 4 + hexval(*p);
       out.push_back(c);
    }
}

You might reasonably ask why one would do it this way when there's strtol, and using it is significantly less code (as in James Curran's answer). Well, that approach is a full decimal order of magnitude slower, because it copies each two-byte chunk (possibly allocating heap memory to do so) and then invokes a general text-to-number conversion routine that cannot be written as efficiently as the specialized code above. Christian's approach (using istringstream) is five times slower than that. Here's a benchmark plot - you can tell the difference even with a tiny block of data to decode, and it becomes blatant as the differences get larger. (Note that both axes are on a log scale.)

Benchmark comparison plot

Is this premature optimization? Hell no. This is the kind of operation that gets shoved in a library routine, forgotten about, and then called thousands of times a second. It needs to scream. I worked on a project a few years back that made very heavy use of SHA1 checksums internally -- we got 10-20% speedups on common operations by storing them as raw bytes instead of hex, converting only when we had to show them to the user -- and that was with conversion functions that had already been tuned to death. One might honestly prefer brevity to performance here, depending on what the larger task is, but if so, why on earth are you coding in C++?

Also, from a pedagogical perspective, I think it's useful to show hand-coded examples for this kind of problem; it reveals more about what the computer has to do.

Zack
-1: ignored standard library facilities. I'd take of an extra point because they were mentioned in previous posts.
André Caron
I ignored them because they're ten times slower than doing it by hand. See edit.
Zack
+1 for focusing on performance, since this is likely to be something used frequently, like in a performance-critical loop. Also for realizing it is not the "correct" textbook answer, and recommending hiding it behind a library function. That's the best place for ugly code like this: behind a pretty interface.
John Gaughan
+1 for the benchmark; though I think James and Christian's implementations are fine for where I am going to use this.
NullUserException
+1  A: 
std::string str("48656c6c6f");
std::string res;
res.reserve(str.size() / 2);
for (int i = 0; i < str.size(); i += 2)
{
    std::istringstream iss(str.substr(i, 2));
    int temp;
    iss >> std::hex >> temp;
    res += static_cast<char>(temp);
}
std::cout << res;
Christian Ammer
+1 [ ](http://www.google.com)
NullUserException
Could pre-allocate, length is known in advance!
André Caron
I hate to say it, but this is five times slower than the accepted answer (which is itself ten times slower than my answer).
Zack
@Zack: I edited my answer and pre-allocate the size of the output string like Caron mentioned and you already did. I'm interested what now are the performance differences between my solution and yours?
Christian Ammer
@Christian: My benchmark program preallocated the output string for all three cases; the only difference was the code inside the for-loop.
Zack