<div dir="ltr">It's likely you can ignore the part about:<div><br></div><div><i><span style="font-size:12.8000001907349px">(N.B. There's another issue here as MSVC then picks the default ctr </span><span style="font-size:12.8000001907349px">basic_istringstream(ios_base::openmode __wch) </span><span style="font-size:12.8000001907349px">to do the "copy construct".  I believe the build should fail.  But this is </span></i><i><span style="font-size:12.8000001907349px">for another time)</span></i></div><div><i><span style="font-size:12.8000001907349px"><br></span></i></div><div><span style="font-size:12.8000001907349px">I had an earlier change which was still hanging around.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 10, 2015 at 2:32 PM, Andrew Parker <span dir="ltr"><<a href="mailto:andrew.j.c.parker@gmail.com" target="_blank">andrew.j.c.parker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">When building and running the test:<div><br></div><div>std/input.output/string.streams/stringstream.cons/move2.pass.cpp<br></div><div><br></div><div>with MSVC I found the test was asserting.  The crux of the issue is that a vector resize isn't preserving the contents of the vector.  Specifically:</div><div><br></div><div>We have a <i>std::vector<std::istringstream> vecis.  </i>The test pushes a default constructed <i>istringstream</i> into the vector.  It then modifies that element in place using the <i>back() </i>member of <i>vector</i> and then by calling the <i>str()</i> member of <i>istringstream.</i>  Things go wrong when the next <i>push_back</i> happens.  This causes the vector to resize and thus reallocate. </div><div><br></div><div>We eventually end up down the callstack in the <i>__construct_backward(allocator_type& __a, _Ptr __begin1, _Ptr __end1, _Ptr& __end2) </i>member of <i>std::allocator_traits.  </i>This calls <i>move_if_noexcept</i> with template parameter <i>std::istringstream&.</i></div><div><i><br></i></div><div>The problem is that this template uses type traits to determine whether to actualy move or just return a reference.  The offending line is:</div><div><br></div><div><i>!is_nothrow_move_constructible<_Tp>::value && is_copy_constructible<_Tp>::value,</i><br></div><div><i><br></i></div><div>with <i>_Tp = </i><i>std::istringstream.</i></div><div><i><br></i></div><div>The declaration of <i>std::istringstream </i>doesn't mark it's move ctr as _NOEXCEPT so <i>is_nothrow_move_constructible </i>is false.  This causes the contents of the vector to be lost as <i>std::istringstream </i>isn't copy constructable (N.B. There's another issue here as MSVC then picks the default ctr <i>basic_istringstream(ios_base::openmode __wch) </i>to do the "copy construct".  I believe the build should fail.  But this is for another time).</div><div><br></div><div>So my question is, should <i>std::istringstream's</i> move ctr be marked _NOEXCEPT?  I'm not sure why this issue doesn't occur with Clang. Thoughts welcomed.  Is this some deficiency in MSVC?  Is this a potential bug and Clang is smart enough to determine <i>std::istringstream</i> is noexcept?  Have I missed a trick? :)</div><div><br></div><div><br></div></div>
</blockquote></div><br></div>