Copying from unsigned char * to the CString

[usman999_1]

Right.
A possible better approach is to write your own "buffer" class like for example:

class CBuffer
{
   unsigned char* buffer;
   unsigned int length;
public:
   CBuffer() : buffer(NULL), length(0) {};
   SetBuffer(unsigned char* src, unsigned int length); 
   unsigned int GetLength() {return length;}
   // and so on, and so on... all you need
};

What is wrong with std::string???

Try this

void DoSomethingWithBinaryData(char* szData, unsigned int nLen)
{

std::string BinaryData;

BinaryData.assign(szData, nLen);

// Now you have access to all those handy functions of std::string and what not

// And to get the data back
 DoSomethingElseWithThisBinaryData(BinaryData.data(), BinaryData.size());
}

Now why would you need a buffer class with managing memory yourself???

Regards,
Usman.

[GCDEF]

What's wrong with std::string???

Depends how you're trying to use it. The data it contains wouldn't work with a lot of C style string functions. As long as you remember what you're doing with it I suppose you could avoid trouble, but a year from now when he forgets it's not compatible with regular const char* functions or future programmer don't know what he's up to, things will work as anticipated.

[Philip Nicoletti]

Depends how you're trying to use it. The data it contains wouldn't work with a lot of C style string functions. As long as you remember what you're doing with it I suppose you could avoid trouble, but a year from now when he forgets it's not compatible with regular const char* functions or future programmer don't know what he's up to, things will work as anticipated.

But if the data contains embedded NULLS, it will not be compatible
with C stsyle string functions to start with. So how does using
std::string make it worse ? Plus you can use the string member
functions and algorithms to search/replace etc.

[usman999_1]

Why do you think it's better than CString?

Well, I dont want to start this CString vs std::string debate all over again. CString is better for MFC functions requiring CString. But CString is designed and should be used as C++ version of c-string (null terminated string), while std::string is more versatile & can act a buffer (for binary or null-terminated data) and provides you will a good api to access and manipulate it.

My 2 cents....

Regards,
Usman.

[Paul McKenzie]

What is wrong with std::string???

Nothing. It can store binary data using the proper member functions, as you've demonstrated.

I think it's just the name "std::string" that gives the impression "it stores only null-terminated strings".

typedef std::string BufferHandler;
//...
BufferHandler buf;

Now it looks "nicer" to say "BufferHandler x" instead of "std::string x".

Regards,

Paul McKenzie

[GCDEF]

But if the data contains embedded NULLS, it will not be compatible
with C stsyle string functions to start with. So how does using
std::string make it worse ? Plus you can use the string member
functions and algorithms to search/replace etc.

Because it's not intuitively obvious to a programmer that sting data will contain embedded nulls. Another programmer may come along and use c_str() method to pass the contents to another function for example. Very few programmers are going to look at any kind of string object and expect its data to contain embedded nulls.

[Philip Nicoletti]

But it is not "intuitively obvious" that an char array will contain
embedded nulls either. If the function that you send the data to
works with NULL terminated strings, it will not work "properly" ...
regardless of whether it is a std::string , CString, custom buffer,
or raw character array.

[ovidiucucu]

Nothing. It can store binary data using the proper member functions, as you've demonstrated.

I think it's just the name "std::string" that gives the impression "it stores only null-terminated strings".

As I have demonstated in my first post, CString isn't obviously containing "only null-terminated strings". Can be also just an impression of outside-MFC visitors.