Failing test when run as C++11

Jonathan Wakely jwakely@redhat.com
Sun May 11 18:39:00 GMT 2014


On 11/05/14 20:16 +0200, Daniel Krügler wrote:
>2014-05-11 19:25 GMT+02:00 Jonathan Wakely <jwakely@redhat.com>:
>> So this actually reveals a latent bug: we use the traits to decide
>> whether we want to use C(const C&) or C(C&&) but then we actually end
>> up using C(C&) or C(C&&), so this fails to compile:
>>
>> #include <vector>
>>
>> struct C {
>> C() { }
>> C(const C&) { }
>> C(C&&){}
>>
>> template<typename T> C(T&) = delete;
>>
>> };
>>
>> int main() {
>> std::vector<C> v(1);
>> v.resize(v.capacity()+1);
>> }
>>
>> With my patch to stl_iterator.h that compiles.
>> I'm not sure if it's required to compile or not. I don't think the
>> standard is clear what should happen here. I'd be interested to know
>> what other implementations do.
>
>My interpretation of the wording is here the same as for my previous
>example: It should work, because C is MoveInsertable and
>DefaultInsertable.
>
>Both clang and Visual Studio 2012 accept the code.

Good to know, thanks.

So my next question is whether they call the copy constructor or the
potentially-throwing move constructor during the resize operation.

Either way I think we need to fix libstdc++ so that
__move_if_noexcept_cond is consistent with what we actually do. The
question is whether to adjust what we do to match the condition (which
is what my patch to stl_iterator.h does) or whether to adjust the
condition to match what we actually do (i.e. replace
is_copy_constructible<C> with is_constructible<C, C&> in the
condition).

I think I need to try the entire testsuite with both options before
deciding, to see if that reveals any unintended consequences.



More information about the Libstdc++ mailing list