Storing byte stream in std::string

[TBass]

Hi,

I'm moving a socket library I wrote from C to C++. In the C version, I
had to malloc char arrays to store incoming communication. My hope was
to use std::string in C++, but then I realized a problem.

While '\0' is a valid string terminator for text, for my purposes it
is a problem. My program regularly gets '\0' as a value (Modbus/RTU
and TCP pass register values as the actual values, not the ASCII
chart). That would be a problem with std::string, I would think, since
it would see the '\0' as the end of a character stream, while, in
actuality, it would be all over the string and not indicate the
termination of the stream.

My question is whether I can write a stream of bytes to std::string,
read the length, and be able to get the whole string back. I expect
that I wouldn't be able to use any of the string functions, but could
I at least get the number of bytes store and get those bytes back at a
later time?

Or should I try a different container?

Thanks in advance,
T

 

[Barry]

Hi,

I'm moving a socket library I wrote from C to C++. In the C version, I
had to malloc char arrays to store incoming communication. My hope was
to use std::string in C++, but then I realized a problem.

While '\0' is a valid string terminator for text, for my purposes it
is a problem. My program regularly gets '\0' as a value (Modbus/RTU
and TCP pass register values as the actual values, not the ASCII
chart). That would be a problem with std::string, I would think, since
it would see the '\0' as the end of a character stream, while, in
actuality, it would be all over the string and not indicate the
termination of the stream.

the representation of std::string doesn't treat '\0' a special
character, which means you an push_back any '\0' at any time.

My question is whether I can write a stream of bytes to std::string,
read the length, and be able to get the whole string back. I expect
that I wouldn't be able to use any of the string functions, but could
I at least get the number of bytes store and get those bytes back at a
later time?

Or should I try a different container?

Well, std::string does NOT guarantee the underlaying memory continuous.

I think std::vector is more like a buffer here, which guarantees
continuous underlying memory.

std::vector<char> buffer;
&buffer[0]; // get the pointer to the first cell.

 

[TBass]

std::vector<char> buffer;
&buffer[0]; // get the pointer to the first cell.

Great. I haven't messed with vector yet. I'll give that a try.

 

[James Kanze]

[...]

Well, std::string does NOT guarantee the underlaying memory
continuous.

It does in the most recent draft. Since the underlaying memory
is contiguous in all current implementations, and will be
guaranteed contiguous in the next version of the standard, I
think you can pretty much count on it.

I think std::vector is more like a buffer here, which guarantees
continuous underlying memory.

std::vector<char> buffer;
&buffer[0]; // get the pointer to the first cell.

You must "resize()" the container (std::string or std::vector)
to the target size before doing this.

 

[TBass]

You must "resize()" the container (std::string or std::vector)
to the target size before doing this.

I did. I went right to vector as the solution, and it is working
nicely. Thank you!

 

[Jim Langston]

I did. I went right to vector as the solution, and it is working
nicely. Thank you!

It should work either in std::string or std::vector, but std::vector is
probably a better fit for binary date since you won't be using std::strings
string manilupating methods anyway.

In one implementation of a socket class I had done I had used std::string
and added each character
buffer += c;
with no problems.

That is one advantage to std::string, the syntax, rather than having to push
back
buffer.push_back(c);
but a small thing.

Either way, you should .reserve() before you start adding to either so the
string or vector won't have to keep resizing itself. Normally it's not much
of an issue but adding one character at a time can cause a large number of
resizes.