> On 1 Apr 2018, at 21:47, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>>> Maybe Bison might support some additional symbol for move action values, >>>> like $$k. >>> >>> I'd thought about this, but it would require changes to Bison itself >>> (for a rather special feature, only for only target language, which >>> can be done in the skeletons), and the user grammar files would also >>> look differently, whereas with my way, they generally look just like >>> they would with shared pointers, or in C, Java, etc., i.e. >>> "$$ = make_foo ($1, $2)". >>> >>> Also "$$k" would look rather similar to "$$" (probably not strictly >>> a conflict, but maybe confusing). >> >> Maybe just add to %code: >> semantic_type&& operator*(semantic_type& x) { return std::move(x); } >> and use *$k, in case this operator is not needed for something else.
Should have been inlined: inline semantic_type&& operator*(semantic_type& x) { return std::move(x); } > If semantic_type doesn't have a "*" operator of its own, this might > work (but look confusing). However, I use the variant (so I'd need > this function for each alternative, which might be possible to do > with templates), but some of my semantic values are (smart) > pointers, so "*" is already used (and even if I could somehow > override it, it would suggest dereferencing rather than moving). Alternative unary operators are listed as point 3 at [1]. One can overload operator&, but is more confusing than *, as it disables taking the address-of. 1. http://en.cppreference.com/w/cpp/language/operator_precedence > Now, if C++ had a dedicated move operator (which would also be > useful in other code) ... But (ab)using an existing operator seems > confusing to me. Or a shorter name.