Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help with char string conversion

Status
Not open for further replies.

Iceman2005

Programmer
May 6, 2005
22
US
okay, this is driving me nuts...

how do i convert a multibyte binary char* string into an std string?

i have two function that returns an...
char* function();
unsigned char* function();

how do i assign them to an std::string ???
it doesnt seem to copy it since the char* may contain multibyte binary data with null in the middle everywhere.

i tried with...

std::string ss = function();
this does not work.

i also tried with....
this seemed to work with char* sometimes.....

for (i = 0; i < length; i++)
ss += buffer;

So guys, what is the CORRECT way to assign a binary char* or unsigned char* into an std::string????


thanks.
iceman
 
OK, first - what kind of string encoding is it? What language?

Windows uses the term "multibyte string" even for single byte ASCII for some strange reason.

If it's a UNICODE wide string, use std::wstring.
 
i'm afraid i am stuck with char* and strings only.
and i need to covert them to string.

my char* contains a string of binary data. perhaps utf8
or just any arbituary binary data.

so there is no way i can call any functions which assumes \0 is the end of the string which it is NOT.
 
If there are embedded nulls, then you must know the size of the string in the character array already. So use the iterator based constructor or assign function to copy the contents of the array into the string:
Code:
char arr[] = { 'a', 'b', 'c', '\0', 'd', 'e', 'f', '\0', 'x', 'y', 'z' };
const unsigned int size = sizeof(arr);

std::string str(arr, arr + size);
// or
str.assign(arr, arr + size);
 
But is std::string really an appropriate container for a string that contains NULLs? It would have to be very clearly documented, otherwise somewhere down the road someone will be in a rush to fix a bug or add a feature and think it's a regular string. If they do str.c_str() to get the string, they'll only see the string up to the first NULL and think that's the whole thing.
Also, how will the other members of the string class work if it has NULLs?
 
Of course std::string is appropriate for a string that contains nulls. The null terminator is just a "hack" in C that allows a string to be passed around without having to pass its size as well. There is no reason to bring that restriction into the C++ string. All std::string functions work with embedded nulls except for the ones that are specifically designed to work with C style strings.

I understand your reservation about how some people just think of string as a container for a C-style string, and in that case if your team generally has a C background I can see using a vector<char> instead. Otherwise I don't see the problem with using std::string.
 
If the whole world threw away C and just used C++, I might agree, but you almost always have to interact with legacy components that use char* strings.

Then again, NULL isn't really a character, and therefore doesn't belong in a string. If you have a "string" that has non-characters in it, then it's really just a chunk of data; so storing it in a class designed for strings is misleading.
 
You probably have a stack problem. What does the declaration of the return value of function look like? It will work if

1) it is newed but you will get a memory leak
2) static but you can't use it twice in the same statement.

It will not work if it is declared on the stack.
 
cpjust said:
I might agree, but you almost always have to interact with legacy components that use char* strings
I disagree. Especially when it comes to strings with embedded nulls. For example, obviously a string with embedded null is not a filename, so it won't be used with fstream. Same with other legacy code.

I still think it can go either way, but there is nothing wrong with using string for this. That's what it is designed for.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top