2

I'd like to copy a fixed length of data from an std::istream to a string:

std::istream & operator >> ( std::istream & is, LogMsg & msg )
{
    // read in 4 bytes - a uint32_t that describes the number of bytes in message:
    // next, read the message bytes into the LogMsg

    typedef std::istream_iterator<unsigned char> Iter;

    Iter            i (is);
    uint32_t        nSize   = 0;
    std::string &   sMsg    = msg.MsgRef();

    is >> nSize;
    sMsg.reserve(nSize);

    std::copy(
        i.begin(), i.begin() + nSize,
        std::back_inserter(sMsg)
    );

    return is;
}

I can't use this solution, as the std::istream_iterator::begin() function on the iterator is c++11 only (I'm constrained to -std=gnu++0x with gcc 4.4.7

So, how can I copy a fixed length of data from an input stream into a string?

I originally loooked at std::istream::read, which seems to fit - it has the following syntax

is.read (buffer,length);

But I don't think you can read into the internal buffers of a string and I'd like to avoid a copy to a temporary buffer. Can I use a streambuf somehow?

stack user
  • 835
  • 1
  • 9
  • 28

3 Answers3

4

The obvious solution is std::copy_n:

std::copy_n( std::istreambuf_iterator<char>( is ), size, std::back_inserter( msg ) );

This will only work if you can be sure that the characters are there, however. If you encounter end of file while trying to read the characters, undefined behavior ensues. Which means that although it is an obvious solution, it maybe isn't a good one.

However, in C++11, officially, and in earlier implementations, in practice, you can read into the internal buffer. You must make sure that the string has enough space:

msg.resize( size );
is.read( &msg[0], msg.size() );

(For some reason, there isn't a non-const version of std::string::data(), despite the guarantee of underlying contiguity in C++11.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329
3

You can copy into a string's internal buffer, just make sure it's the right size:

sMsg.resize(nSize);
is.read(&sMsg[0], nSize);

It's less efficient than the solution with begin() since you have to zero-initialize a whole bunch of data that you're immediately overwriting. But it will work pre-C++11.

Barry
  • 286,269
  • 29
  • 621
  • 977
  • Technically this is UB pre-C++11. – Lightness Races in Orbit Nov 21 '14 at 12:43
  • Contiguity not strictly guaranteed. Though in practice it _sort of_ was. Actually as of GCC 4.9 I think they're still using the old implementation with COW, which is non-compliant in C++11. Moral of the story, be very careful with direct string access. – Lightness Races in Orbit Nov 21 '14 at 12:45
  • @LightnessRacesinOrbit But in practice, it will work. – James Kanze Nov 21 '14 at 12:47
  • @LightnessRacesinOrbit Contiguity was not guaranteed intentionally, in order to allow implementations along the lines of `rope`. In practice, no one ever used them, so they added the contiguity guarantee. And the g++ implementation of `std::string` has always been contiguous; the above will work with it. – James Kanze Nov 21 '14 at 12:49
  • @James: [I don't believe that's true](http://stackoverflow.com/a/21431742/560648); JW says [strings are still COW in GCC 4.9](http://stackoverflow.com/questions/21431633/does-g-meets-stdstring-c11-requirements#comment32348898_21431742) and doesn't that kill the contiguity guarantee? Wait, does it? Hm. Yeah, [never mind I guess not](http://stackoverflow.com/a/1986974/560648). – Lightness Races in Orbit Nov 21 '14 at 12:51
  • @James: As for it being "intentional", that was called into question in C++98 the first time somebody noticed that `std::string::data()` and `std::string::c_str()` have constant time complexity. The fact that the change made was to enforce contiguity rather than give `std::string::c_str()` non-constant complexity says quite a lot. – Lightness Races in Orbit Nov 21 '14 at 12:54
3

Use std::copy_n():

std::copy_n(i, nSize, std::back_inserter(sMsg));
David G
  • 94,763
  • 41
  • 167
  • 253