This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Failing test when run as C++11
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Daniel KrÃgler <daniel dot kruegler at gmail dot com>
- Cc: Jonathan Wakely <jwakely at redhat dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Sun, 11 May 2014 22:24:15 +0100
- Subject: Re: Failing test when run as C++11
- Authentication-results: sourceware.org; auth=none
- References: <20140509105321 dot GD10556 at redhat dot com> <CAGNvRgBEuc1qSiPA41-AiVifoW0aLXYVwQZK+O-SiODxauQDew at mail dot gmail dot com> <20140509112018 dot GE10556 at redhat dot com> <20140509121054 dot GH10556 at redhat dot com> <CAGNvRgB1A0CThLiiPU6zt1Q1ARNwkBeSNiKczbv8t3W-75Fn2w at mail dot gmail dot com> <20140509124308 dot GI10556 at redhat dot com> <20140509134605 dot GJ10556 at redhat dot com> <CAGNvRgB4wtokz6haAnYv9XUNoR75TJ_zKSDttJ8VuF4QgXe4Zw at mail dot gmail dot com> <20140511172515 dot GN10556 at redhat dot com> <CAGNvRgAMt=0Php9Bi7OvLbQy6rJkdox0ejyO=fMoRjZjDuRvZQ at mail dot gmail dot com> <20140511183916 dot GO10556 at redhat dot com> <CAGNvRgAYeM6SBE4rOixdWaJywR9LjrQ5sGQLSjx5Sp9tEbb1Lg at mail dot gmail dot com>
On 11 May 2014 21:25, Daniel KrÃgler <daniel.kruegler@gmail.com> wrote:
> 2014-05-11 20:39 GMT+02:00 Jonathan Wakely <jwakely@redhat.com>:
>> 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.
>
> Both invoke the move constructor. And I don't see why this would
> conflict with the requirements of resize().
So going back to this point ... I don't see how they can offer the
strong guarantee (as required by resize()) if they use a move
constructor that could throw.