[libcxx-dev] std::vector using copy constructor on existing elements during reserve()

Wed Apr 17 16:44:45 PDT 2019

> On 2019 Apr  17, at 11:06, Louis Dionne <ldionne at apple.com> wrote:
> 
> 
> 
>> On Apr 17, 2019, at 13:38, JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>> 
>> 
>> 
>>> On Apr 17, 2019, at 10:12 AM, Louis Dionne via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 17, 2019, at 12:39, Duncan P. N. Exon Smith <dexonsmith at apple.com <mailto:dexonsmith at apple.com>> wrote:
>>>> 
>>>> I'm curious about how people feel this should/could behave with -fno-exceptions.  IIRC, Libc++ calls the copy constructor (following the standard), but -fno-exceptions isn't really standard, and from a user perspective that doesn't make sense.  `noexcept` is essentially meaningless with -fno-exceptions.
>>> 
>>> I personally feel like it would be surprising if -fno-exceptions caused the move constructor to be called instead of the copy constructor. My mental model is that -fno-exceptions only disables exceptions as a language feature, but doesn't really instruct libraries to provide a different API (even though the difference in this case is very small). Instead, I feel like it would make more sense if "everything" was implicitly marked noexcept when -fno-exceptions is used (because that's really the case). The library would behave optimally with -fno-exceptions without having to do anything special.
>> 
>> IIUC what you’re saying: the library should just use the noexcept operator to do its business, and it seem like -fno-exceptions should make noexcept always return true? That would be pretty consistent (more than teaching the library about -fno-exceptions for move / copy).
> 
> Yes, that's what I mean. I agree with Eric that moving instead of copying provides value, but I think the right way to do it is not to special case libc++, but instead to have all code bases become better under -fno-exceptions by making noexcept do the right thing.

Yeah, that makes sense to me too.

+Richard, I could have sworn you and I chatted quickly about this back in 2016 by my mail-search-fu is failing me.  What are your thoughts on having -fno-exceptions affect the value of `noexcept`?

>> 
>> 
>>> Louis
>>> 
>>>> 
>>>> Thoughts?
>>>> 
>>>>> On Apr 16, 2019, at 23:19, Eric Fiselier via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Apr 16, 2019 at 2:25 PM Michael Narigon via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>>> std:vector is using the element copy constructor on existing elements during its resizing operation in reserve(). I would expect it to use the move constructor for efficiency. Is this intended behavior?
>>>>> 
>>>>> Yes, this behavior is mandated by the standard. The copy constructor is used when the move constructor is not noexcept. From cppreference's `std::move_if_noexcept` documentation:
>>>>> 
>>>>> std::vector::resize <https://en.cppreference.com/w/cpp/container/vector/resize>, which may have to allocate new storage and then move or copy elements from old storage to new storage.
>>>>> If an exception occurs during this operation, std::vector::resize <https://en.cppreference.com/w/cpp/container/vector/resize> undoes everything it did to this point, which is only possible if
>>>>> std::move_if_noexcept was used to decide whether to use move construction or copy construction. (unless copy constructor is 
>>>>> not available, in which case move constructor is used either way and the strong exception guarantee may be waived)  
>>>>>  https://en.cppreference.com/w/cpp/utility/move_if_noexcept <https://en.cppreference.com/w/cpp/utility/move_if_noexcept>
>>>>> 
>>>>> If you add `noexcept` to your move constructor, vector should call the move constructor.
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> This is with the libc++ delivered with Xcode 10.1.
>>>>> 
>>>>> Attached is a sample program displaying the behavior.
>>>>> _______________________________________________
>>>>> libcxx-dev mailing list
>>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>>>> _______________________________________________
>>>>> libcxx-dev mailing list
>>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>>> 
>>> 
>>> _______________________________________________
>>> libcxx-dev mailing list
>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190417/c0b7eb17/attachment.html>