<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 1, 2020, at 4:07 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class="">Can you spell this out for me? Why do we need noexcept if we’re building with -fno-exceptions? What is going on here?</div></div></div></blockquote><br class=""></div><div class="">Sure. It's a bit convoluted. Here's my understanding:</div><div class=""><br class=""></div><div class="">First, here's why std::vector has this behaviour:</div><div class="">- std::vector grow operations need to transfer their existing elements over to the new storage.</div><div class="">- The grow operations are usually required to meet the "strong exception guarantee": if something throws, this function has no effect.</div><div class="">- If move operations throw, you can't provide this guarantee unless you copy (you can't move back the elements that have been half-moved over, in case another exception is thrown; but if it was just a copy, the original storage still has the elements safely unmodified).</div><div class="">- There's a caveat / carve out, that if T cannot be copy-constructed AND T's move constructor is not noexcept, then the guarantee is waived (since there's no way to implement it).</div><div class="">- Implementation is to call std::move_if_noexcept (<a href="https://en.cppreference.com/w/cpp/utility/move_if_noexcept" class="">https://en.cppreference.com/w/cpp/utility/move_if_noexcept</a>), which moves if it's a noexcept operation, or if T is not copy-constructible.</div><div class=""><br class=""></div><div class="">Second, here's why the behaviour doesn't change when -fno-exceptions:</div><div class=""><div class="">- -fno-exceptions does NOT imply `noexcept` (maybe it should?, but it doesn't).</div></div><div class="">- This is implemented by detecting via SFINAE whether something is `noexcept` (maybe std::vector::resize/push_back/etc should have a special case? but that's controversial).</div><div class=""><br class=""></div><div class="">IMO, until all the C++ standard libraries and host compilers that we support being built with will consistently use std::move on grow operations in std::vector in -fno-exceptions mode, we should only use std::vector when we absolutely have to. It's not designed for -fno-exceptions codebases</div></div></div></blockquote><div><br class=""></div><div>Wow, thank you for the great explanation. I agree with you that this seems like a pretty credible reason why we can’t depend on every host std::vector to do what we need, so we should use something like an llvm::Vector.</div><div><br class=""></div><div>Two thoughts:</div><div><br class=""></div><div>1) are you, or anyone else, interested in driving an llvm::Vector proposal + coding standard change to get us going in the right direction? I don’t think we need a mass migration of the code base, just get the policy aligned right plus the new type name to exist.</div><div><br class=""></div><div>2) I think we should pursue Richard’s proposal or something like it to make Clang provide better C++ performance out of the box. I assume that all the STL containers will have similar issues (not to mention user defined ones), and noexcept isn’t widely used. Some flag that turns noexcept on by default (or for everything even with an exception spec?) in -fno-exceptions mode seems like a great thing to do.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">.</div><div class=""><br class=""></div><div class="">(</div><div class="">There's some discussion in this thread:</div><div class=""><div class=""><a href="http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000344.html" class="">http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000344.html</a></div><div class=""><div class=""></div><div class=""><br class=""></div></div><div class="">And Richard had a proposal that made sense to me:</div><div class=""><a href="http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000343.html" class="">http://lists.llvm.org/pipermail/libcxx-dev/2019-April/000343.html</a></div><div class=""><div class=""></div><blockquote type="cite" class=""><div class="">I'm wondering if we should have an experimental</div><div class="">option to specify that functions are noexcept by default (overridable</div><div class="">by an explicit exception specification)</div></blockquote></div><div class=""><br class=""></div><div class="">But that only fixes it in host compilers that implemented this experimental mode.</div><div class="">)</div></div></div></div></blockquote></div><br class=""></body></html>