By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,018 Members | 894 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,018 IT Pros & Developers. It's quick & easy.

using string as a character buffer in unix system calls

P: n/a
I have gotten in the habit of using strings to manage character buffers
that I pass in to unix system calls.

For example, suppose I want to create a character buffer to use with
the "write" system call.

string buf(1024);
int fd;
write(fd,(void *)(&buf[0]),buf.size());

It recently occured to me that the standard C++ library doesn't
necessarily guarantee that a vector<char> or string will be implemented
in terms of a single c array of char, so that by taking creating a
pointer to the first element of the string or vector and passing it
into a function expecting a c array of char I could be making my
programs non-portable.

Does anyone know if the standard makes any guarantees one way or the
other?

Does anyone find my practice a bad idea?

Chris

Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
ch******************@yahoo.com wrote:
I have gotten in the habit of using strings to manage character buffers
that I pass in to unix system calls.

For example, suppose I want to create a character buffer to use with
the "write" system call.

string buf(1024);
int fd;
write(fd,(void *)(&buf[0]),buf.size());
Ugh! Should most likely be

write(fd, buf.c_str(), buf.size());


It recently occured to me that the standard C++ library doesn't
necessarily guarantee that a vector<char> or string will be implemented
in terms of a single c array of char, so that by taking creating a
pointer to the first element of the string or vector and passing it
into a function expecting a c array of char I could be making my
programs non-portable.
Not really. If you use &somevector[0], you're most likely fine because
in the next standard the contiguousness of the vector storage will be
required (and all current implementations already do that). For a string
you should use 'c_str()' anyway.
Does anyone know if the standard makes any guarantees one way or the
other?
c_str() returns a pointer to the first character of an array, and that
pointer remains valid until a call to a non-const member function. What
you shouldn't attempt doing is _reading_ into that area.
Does anyone find my practice a bad idea?


No. Just do it right. And don't _read_ into a string. For that you
should use a vector or a plain array.

V
Jul 23 '05 #2

P: n/a
Victor:

Thanks for the quick reply!

I goofed in my example. I should have declared my buf like this:

vector<char> buf(1024);

It is interesting that the next standard will require contiguousness of
storage in vectors. I wonder what reasons pushed that into being an
explicit issue?

Your c_str() point was well taken. Also the one about not reading into
a string through the address of its first element.

Chris Marshall

Jul 23 '05 #3

P: n/a
ch******************@yahoo.com wrote:
[..]
It is interesting that the next standard will require contiguousness of
storage in vectors. I wonder what reasons pushed that into being an
explicit issue?


I think it's the same reason that drove you to use &v[0] to read into or
write from the vector's storage. People have too much legacy stuff that
needs an array. A vector is a good replacement for the C++ arrays _if_
you allow using its storage for direct access through a pointer to the
first element. Turned out to satisfy other requirements vector could not
have non-contiguous storage, so it was decided to legalize that drug.
At least that's how I remember it. You can find out better if you ask
in comp.std.c++ were they talk Standard document.

V
Jul 23 '05 #4

P: n/a
Me
Victor Bazarov wrote:
string buf(1024);
int fd;
write(fd,(void *)(&buf[0]),buf.size());


Ugh! Should most likely be

write(fd, buf.c_str(), buf.size());


I think it's better to use buf.data() here instead.

Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.