How can I insert null bytes in to std::string?

[Pep]

I have to interface to an older library that uses strings and there is
no alternative. I need to pass a string that is padded with null
bytes. So how can I append these null bytes to the std::string?

Yes I know it would be better to use something like a vector but I do
not have that option.

Yes I know that I will not be able to use std::string.c_str() but will
instead have to use std:;string.getData().

TIA.

 

[Victor Bazarov]

I have to interface to an older library that uses strings and there is
no alternative. I need to pass a string that is padded with null
bytes. So how can I append these null bytes to the std::string?

Probably using "append" member... Have you RTFM?

Yes I know it would be better to use something like a vector but I do
not have that option.

In your case it probably does not matter. Why do you think that 'vector'
has any advantage?

Yes I know that I will not be able to use std::string.c_str() but will
instead have to use std:;string.getData().

Just like with a 'vector', you can always use the address of the first
char...

V

 

[Pep]

Probably using "append" member... Have you RTFM?

Yes but it was suggested to me that there was a way that did not
involve using append, so as I could not find any way I decided to ask
if anyone knew of one of those "tricks".

Guess it will have to be append then.

In your case it probably does not matter. Why do you think that 'vector'
has any advantage?

I read something in a previous posting that suggested vectors would be
better though as you, I do not understand how other than perhaps the
poster meant that you should not in theory have nulls in strings.

Just like with a 'vector', you can always use the address of the first
char...

For some reason I opted for the getData being better than c_str as it
implies it is the correct method by it's name.

V

Thanks for the help.

 

[Daniel T.]

Yes I know that I will not be able to use std::string.c_str() but will
instead have to use std:;string.getData().

Just like with a 'vector', you can always use the address of the first
char...[/QUOTE]

Really? I didn't think the standard guaranteed that a std::string was
contiguous like vector is?

 

[Daniel T.]

I have to interface to an older library that uses strings and there is
no alternative. I need to pass a string that is padded with null
bytes. So how can I append these null bytes to the std::string?

The above doesn't quite make sense. C strings can't have null bytes in
the middle of them so why would you need to append null bites? If you
are talking about the null at the end of the string, then the
member-function c_str() does that for you, you don't need to.

Yes I know it would be better to use something like a vector but I do
not have that option.

I'm personally not so sure that it would be better to use "something
like a vector" but you know your problem space better than us.

Yes I know that I will not be able to use std::string.c_str() but will
instead have to use std:;string.getData().

Why can't you use c_str()? The only difference between c_str() and
data() [not getData()] is that c_str appends a null on the end. Isn't
that what you want?

 

[Victor Bazarov]

Just like with a 'vector', you can always use the address of the
first char...

Really? I didn't think the standard guaranteed that a std::string was
contiguous like vector is?[/QUOTE]

No, there is no such guarantee, you're correct (at least I can't find it).

V

 

[Victor Bazarov]

[...]
For some reason I opted for the getData

You mean 'data()', of course, no? 'data()' and 'c_str()' are essentially
the same.

V

 

[peter koch]

The above doesn't quite make sense. C strings can't have null bytes in
the middle of them so why would you need to append null bites? If you
are talking about the null at the end of the string, then the
member-function c_str() does that for you, you don't need to.

This is not true - sort of anyway:

char const* weird_hello = "Weird \0hello";

does contain an embedded null and if'd call it a C-string you surely
are wrong! ;-)
I've seen a list of lines being defined with a \0 separating each
string and using an empty string as a terminator. Something like 'H'
'e' 'l' 'l' 'o' 0 'W' 'o' 'r' 'l' 'd' '!' 0 0.

My guess is the OP wanted to have two nulls at the end of the string-
Another possibility is that the interface expects the string in a
fixed-length buffer and the buffer to be containing zeroes at the end
of the string. You believe I'm kidding, but I've actually witnessed
such an interface once.

I'm personally not so sure that it would be better to use "something
like a vector" but you know your problem space better than us.

/Peter

 

[Alf P. Steinbach]

* Victor Bazarov:

No, there is no such guarantee, you're correct (at least I can't find it).

Pete Becker posted earlier (many months ago, early March?) that this
guarantee for std::basic_string was approved that day by the Library
Working Group and would be voted into the Working Draft, as I understood
it the next day or week or so, so presumably it has been so voted, and
will be present in C++0x.

 

[Daniel T.]

This is not true - sort of anyway:

char const* weird_hello = "Weird \0hello";

does contain an embedded null and if'd call it a C-string you surely
are wrong! ;-)

I'd call that two c-strings, but I grant that you may very well be right
and this is exactly what the OP wants.

 

[fungus]

Yes but it was suggested to me that there was a way that did not
involve using append, so as I could not find any way I decided to ask
if anyone knew of one of those "tricks".

Doing anything outside of the standard wouldn't
be a "trick" it would be "undefined behaviour".



--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again. They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

 

[Daniel T.]

Yes but it was suggested to me that there was a way that did not
involve using append, so as I could not find any way I decided to ask
if anyone knew of one of those "tricks".

Guess it will have to be append then.

Well, you could always do: "myString[pos] = 0" if you know that pos is a
valid position.

 

[Ivan Vecerina]

:
: Victor Bazarov wrote:
: > Pep wrote:
: > > I have to interface to an older library that uses strings and there
is
: > > no alternative. I need to pass a string that is padded with null
: > > bytes. So how can I append these null bytes to the std::string?
: >
: > Probably using "append" member... Have you RTFM?
: >
:
: Yes but it was suggested to me that there was a way that did not
: involve using append, so as I could not find any way I decided to ask
: if anyone knew of one of those "tricks".
:
: Guess it will have to be append then.

And what's wrong with it ?
s.append( 5, '\0' ); // appends five NULs, pretty straightforward?

: > > Yes I know it would be better to use something like a vector but I
do
: > > not have that option.
: >
: > In your case it probably does not matter. Why do you think that
'vector'
: > has any advantage?
:
: I read something in a previous posting that suggested vectors would be
: better though as you, I do not understand how other than perhaps the
: poster meant that you should not in theory have nulls in strings.

Vector historically had to be used if you wanted write
access *and* contiguous storage (because only .data()
and .c_str() were guaranteed to return a pointer to
contiguous storage, and the returned buffer is *const*).

But using &s[0] has always worked in practice,
and the standard has been revised to allow this
[ contiguity is now always guaranteed ]


: > > Yes I know that I will not be able to use std::string.c_str() but
will
: > > instead have to use std:;string.getData().
..c_str() might have an advantage over .data() in your case:
it will append an additional NULL char to the returned buffer


Cheers --Ivan

 

[Pep]

peter koch wrote:

This is not true - sort of anyway:

char const* weird_hello = "Weird \0hello";

does contain an embedded null and if'd call it a C-string you surely
are wrong! ;-)
I've seen a list of lines being defined with a \0 separating each
string and using an empty string as a terminator. Something like 'H'
'e' 'l' 'l' 'o' 0 'W' 'o' 'r' 'l' 'd' '!' 0 0.

My guess is the OP wanted to have two nulls at the end of the string-
Another possibility is that the interface expects the string in a
fixed-length buffer and the buffer to be containing zeroes at the end
of the string. You believe I'm kidding, but I've actually witnessed
such an interface once.

Correct. I have taken over a large legacy system a long time ago and
still have not got to grips completely with it. The previous
programmers, all juniors, have coded a method that only caters for
strings and yet we need to send binary data through it now. You would
think that a hex encoder/decoder would deal with binary data wouldn't
you?

So without going to the lengths of changing millions of lines of code,
it would have been nice to send binary data in the string and let the
latest method in the encoder, which deals with char* arrays, to handle
it.

In the end I got completely pissed off and spent an extra 2 days
writing a proper encoder and then updating the massive code deck to
accommodate it. Now it all works correctly, encoding from binary to
string and decoding form string to binary

<snip>