byte * to CString

All that you need it's sscanf() function.
Some references you can find here:
http://www.dev-archive.com/forum/showthread.php?t=231056
http://www.dev-archive.com/forum/showthread.php?t=231054
I think that's all that you need.
Enjoy! ;)

Why do you need to put a BYTE* into a CString?
Nice question, Siddhartha! :wave:

If you are not doing a UNICODE build thus TCHAR = char then you can do the following:

byte b[] = { 'a', 'b', 'c'};
CString str( (LPCTSTR) b, 3);

In your case it would be:

CString myfunc(byte * pData, unsigned long datalength)
{
return CString( (LPCTSTR) pData, datalength);
}

Only if byte * pData is atually a string and not some various data. ;)

ofc :)

This code is correct but it is painfully slow. If you invoke it rarelly than it is almost ok but I would try to find a faster ( than VB) solution. :D

PS: although at this time of the day and ahead of a big footbal game I cannot think of anything faster. ;)

The (laughed at) question "why?" is still not answered...
What's a "byte"?
8 bits?
And what's in pData?
A pointer (possibly invalid) to 8 bits.

:D :D :D :D

Sorry, I just couldn't resist!!!

Viggy

It should be in 'windef.h':
typedef unsigned char BYTE;
Viggy

D'OH, I missed that (it was Siddhartha's response that threw me).

;)

Vig.

I do know "BYTE", the "byte" I have a problem with...
It's enought to include <windows.h> to have your compiler recognize byte.

Here is a practical example of "putting BYTE* into a CString":I am not looking for random examples.

My question was posed to the OP, and I wished to know the need for this conversion as not every BYTE* points to a NULL terminated string.
lpData = new BYTE[cbData];
::RegQueryValueEx(hKey, _T("FaceName"), 0, &dwType, lpData, &cbData);
CString strFaceName = (LPCTSTR)lpData; Note that you are actually assigning a TCHAR* (which is pointed to by a BYTE*) into a CString - nothing else (lets ignore the missing terminating NULL character in the buffer - relying excessively on API behaviour).

A different way of coding the same would be -
TCHAR* lpData = new TCHAR [cbData / sizeof (TCHAR) + 1];
memset (lpData, 0x00, cbData + sizeof (TCHAR));

::RegQueryValueEx(hKey, _T("FaceName"), 0, &dwType, (LPBYTE)lpData, &cbData);
CString strFaceName (lpData);

delete [] lpData;There isn't anything practical about BYTE* to CString conversion.

I should imagine how happy can you be when ignore my NOTEs to point "something wrong" in my example(s).It wasn't just something wrong - assigning a non-NULL terminated string to a CString will certainly cause a memory overrun. This is not trivial.
In fact, you have made the same thing in a little bit harder to read ...My point is exactly that - it is the same thing in two different ways - both are TCHAR* and not BYTE* - as both contain NULL terminated strings.
Well, we can continue that way, if you wish: you also didn't check the cbData value gotten after the first call. What about if a wise guy has put in that registry value something huge?...What is huge? If a value I need is in the registry, and is dynamically allocated for - where is the question of huge or small?

Bottomline was just that there are few practical reasons why a BYTE* passed to a function should be asssigned to a CString, and my question was posed to the OP.

Returning to the other issue discussed here:
What are 'BYTE' and 'byte' identifiers we are talking about? As already pointed before, they are aliases (typedef(s) declared in WINDEF.H and RPCNDR.H, respectively) of fundamental type 'unsigned char', which is one of types guaranteed by standard having 1 byte length:
ISO C++
The sizeof operator yields the number of bytes in the object representation of its operand.
[...]
sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result of sizeof applied to any other fundamental type is implementation-defined.
And what is a byte?
ISO C++
The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain
any member of the basic execution character set and is composed of a contiguous sequence of bits, the
number of which is implementation-defined.
/i think it's pretty clear, although I'm afraid, my friend Sid has something to add... :D ;)

LOL :D 2xLOL :D 3xLOL :D
I would prefer 0xE0F which is syntactically correct... :D

OK, let's return on topic.