On Samstag, 30. Januar 2021 18:10:32 CET Akim Demaille wrote: > Hi Christian, > > I don't know how I managed to not see your answer about this, > but I just discovered it, when I was about to ask for more > feedback...
My good old camouflage emails. Np, Akim. :) > > Le 19 janv. 2021 à 13:36, Christian Schoenebeck <schoeneb...@crudebyte.com> a écrit : > >> diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4 > >> index cfd4e6ed7..3496450e2 100644 > >> --- a/data/skeletons/c++.m4 > >> +++ b/data/skeletons/c++.m4 > >> @@ -309,7 +309,9 @@ m4_define([b4_symbol_type_define], > >> > >> #if 201103L <= YY_CPLUSPLUS > >> > >> /// Move constructor. > >> > >> - basic_symbol (basic_symbol&& that) > >> + basic_symbol (basic_symbol&& that)]b4_variant_if([ > >> + YY_NOEXCEPT > >> (]b4_type_foreach([b4_is_nothrow_move_constructible], > >> [[ + && ]])[)])[ > >> > >> : Base (std::move (that)) > >> > >> , value (]b4_variant_if([], [std::move > > > > AFAICS you are conditionally inserting the C++ 'noexcept' qualifier to > > class "basic_symbol"'s constructor (by using C++ type trait > > std::is_nowthrow_move_constructible()), and at the same time you are still > > always using std::move() below though. > > I'm unsure which "conditionally" you are referring to. The > macro YY_NOEXCEPT is conditioned by whether this is at least > C++11. Which is useless in the present case since we are > already within "#if 201103L <= YY_CPLUSPLUS". I'll simplify > that. > > And the noexcept itself depends on whether all the types > support nothrow move-construction. Yes, that's how I was reading it as well then. > > that should be > > either noexcept & std::move() otherwise no std::move() at all, at least > > with recent compilers. > > Really? What mandates that? I can see it is good style, Yeah, I had a quick lookup and did not see it specified either. From my memory the idea was if an exception was thrown while std::move() is in progress, then it may leave it in an "undefined state". > but the standard library is expected to use things such as > move_if_noexcept to relieve us from having to not define > move ctors in this case. Yes, but in your patch you were not using std::move_if_noexcept() which is a wrapper for conditionally using std::move() if its nothrow, otherwise it automatically uses a temporary value for safety instead. > And if that's true, that would mean > I'd have to play ninja tricks (read sfinae) to do that, and I'm > no longer in that mood :( If someone wants to tell me what is > expected in replacement of Well, you already came up with an obvious approach; using std::move_if_noexcept() instead of std::move(). Whether that was actually the cause of the compiler crash you got there is another question, as I don't have a reproducer. Best regards, Christian Schoenebeck
