Re: C++ token move constructors/assignment with LALR

[Frank Heckenbach]

Anthony Heading wrote:

> Reminded by the mention of automove in the previous thread,  I
> agree it works really well, though for one of my uses I needed to
> add the move operators to my local C++ skeleton.
> 
> So I was happy to see these were recently added in the bison repo:
> "This will be used in glr2.cc, which requires C++11.", but then
> sad to see them explicitly hidden from the other skeletons:
> "don't publish move ctor to lalr1.cc".    Shouldn't the C++
> version requirement ideally be determined in part from the user
> semantic type definition?  It seems a reasonable thing for a user
> to want a move-only type with an LALR1 grammar?  Or is the lalr.cc
> skeleton somewhat frozen/obsolescent/deprecated now and only GLR
> is recommended for new code?

I'm not a bison maintainer, though I was involved in the development
of the move feature, so I'm a bit surprised.

AFAIK, move works well in lalr1.cc, which I use myself.
I don't think GLR is recommended when its power is not needed.

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.

This might be because lalr1.cc can work with pre-C++11 and uses
explicit moves, so it doesn't need the move assignment operator, so
it's hidden to avoid any unforeseen consequences. Whereas glr2.cc
requires C++11 and thus (I assume) fully uses C++11 move semantics.

But even lalr1.cc uses move semantics when possible (via YY_MOVE),
so it should be alright. If you want to test it, you can use a
move-only value type (e.g. std::unique_ptr). If it compiles, it must
be moving.

BTW, when checking this, I noticed there's a "void move" function
declared (actually 3 of them for different classes) in the skeletons
which I thought were involved here, but there doesn't seem to be any
definition of them. So these declarations may be remnants, and you
might want to remove them, Akim.

Viele Grüße,
Frank