On Thu, Apr 21, 2022, at 1:57 AM, Frank Heckenbach wrote:
> The comment you quoted seems to refer only to the move assignment
> operators, not the move constructors which are conditional on
> "201103L <= YY_CPLUSPLUS" instead.

Totally right, yes it is only the move assignment which was missing / now 
hidden,  and that's actually the most immediate problem.   Assuming of course 
it's agreed to be a problem at all,  as I concur the skeleton doesn't use it.   
 I think the issue arises if the user wants to assign the tokens (which I think 
is natural, e.g. for lexer putback and so on) and starts even with simple 
types. 

---
%language "c++"
%skeleton "lalr1.cc"
%define api.token.constructor
%define api.value.type variant

%token <int> INT

%{

#include <base/base.h>
#include "foo.y.h"

using namespace yy;

parser::symbol_type yylex();

%}

%%

start :

%%

void parser::error(const string &) { }

parser::symbol_type yylex()
{
    return parser::make_INT(12345);
}

int main() {
    parser::symbol_type sym;
    sym = yylex();
    return 0;
}
---

foo.y:34:9: error: object of type 'parser::symbol_type' cannot be assigned 
because its copy assignment operator is implicitly deleted
    sym = yylex();
        ^
obj/foo.y.h:625:26: note: copy assignment operator of 'symbol_type' is 
implicitly deleted because base class 'basic_symbol<yy::parser::by_kind>' has a 
deleted copy assignment operator
    struct symbol_type : basic_symbol<by_kind>
                         ^
obj/foo.y.h:475:7: note: copy assignment operator is implicitly deleted because 
'basic_symbol<yy::parser::by_kind>' has a user-declared move constructor
      basic_symbol (basic_symbol&& that)
      ^
1 error generated.

---

So because there is no move assignment operator,  C++ tried to fall back to 
(implicit) copy assignment, but it can't even manage that because there IS a 
move constructor.

Enabling the move assignment operator in the skeleton fixes this,  and works 
for unique_ptr etc too.



Reply via email to