Re: C++11 move semantics

[Frank Heckenbach]

Hans Åberg wrote:

> > It would work in C, but users were advised not to rely on it.
> 
> No problem in C, as there are no copy constructors, just an overhead.

I think users were advised against it because it was just an
accidental feature and not guaranteed (in the case of explicit
actions). Anyway, that's only of historical interest now.

> > That's what I thought too, but it doesn't seem to (and it wouldn't
> > work with move-only types without std::move). It just seems to leave
> > $$ unset (i.e. default-constructed) without an explicit action.
> 
> If you don't have an {...}, one should get $$ = $1.

Should, but apparently doesn't (in C++).

> >>> But anyway, the issues with unique_ptr and other move-only types are
> >>> not mainly in the actions, but more in the generated code, starting
> >>> with the make_FOO functions. Again, I don't see that the default
> >>> versions in 3.0.4 support moving. Do you use another version?
> >> 
> >> No versions support moving, and 3.0.4 may be the latest. The
> >> objects must be locations where it is expires, and that may not
> >> work well with the Bison parser.
> > 
> > Sorry, I don't quite understand your last sentence.
> 
> Even with a type support move constructors, the $$ and $k are not in 
> positions where they will be invoked.

I don't follow you. I was talking about the make_FOO functions which
are usually called from the lexer, no $$ and $k involved. For parser
actions, one needs to write std::move manually, that's understood
and it works. There are also places in the parser generated code
that don't support moving, but if already the first step (make_FOO)
doesn't, how should move-only types work?

Note, this was still in reply to your initial statement that Bison
works with unique_ptr; meanwhile you said it doesn't support move
semantics, so the point may be moot now. (I think the
misunderstanding stems from you thinking unique_ptr doesn't require
move semantics; in fact it's the prototypical move-only type in the
standard library.)

> > That's the problem: If Bison isn't developed, the skeleton file
> > won't change, so I could (and would have to) keep my changes
> > locally. But if it's developed and the skeleton file changes, I'd
> > like my version to benefit, so I'd like to get it integrated. If
> > Bison doesn't want to require C++11, my changes could be made
> > conditional, either with #ifdef or with m4 macros. I'd be willing to
> > work on that, but only if there's a point to it, i.e. if Bison is
> > still maintained.
> 
> That is complicated. I jave tried it, so I decided to not do it.

Well, #ifdef is not complicated, just a little tedious. Maybe even
not so bad; with some clever macros for "const T&" vs. "T &&", "v"
vs. "std::move (v)" and "YYASSERT" vs. "static_assert", I think it
would be ~10 conditionals for all of my patches.

Probably similar with m4 macros, though probably more complicated
(to me) as I'm not familiar with Bison's use of m4.

> >>> But again, what/where is this "untyped grammar C++ parser" you
> >>> mentioned? I might try it, but I don't see it anywhere.
> >> 
> >> Just don't use %union.
> > 
> > Actually, I'm not using %union, but "%define api.value.type variant"
> > just like in the calc++ example.
> 
> There was a report on som issue with that. So it would be better no using it 
> now.
> 
> > Do you mean using an "untyped"
> > semantic type, i.e. a kind of variant manually? But it would still
> > need to be copyable, or does moveable suffice then?
> 
> The types one writes in the grammar selects fields in the %union
> or variants.

Sure, that's what I'd expect.

> For C++ it seems safest to not use the variants it has in view of
> that issue.

Which issue? If the parser code, or a user action via $<foo>$
selects a wrong variant, the assertions (which I'll keep enabled)
will catch it. In this regard, no big difference to C++17 variants
which will throw an exception then.

> >>> And when you say "the typed does not work properly", are you
> >>> referring to lalr1.cc? What doesn't work? With the calc++ example
> >>> I saw no problems, but it's just a toy, of course. So if there are
> >>> serious problems, I'd like to know about them before I try to port
> >>> my parser.
> >> 
> >> It was an issue with the variants.
> > 
> > Well, I read variant.hh, and I did't spot any serious problems.
> > Whatever the issue was, maybe it's fixed now.
> 
> I don't think so, in view of that the C++ parser isn't developed. You might 
> try searching the archives.

Well, search for what?

> >> You might start with unique_ptr to see if it suffices. There is no
> >> Bison support for move semantics to be expected any time soon.
> > 
> > I do want to start with unique_ptr, but unique_ptr requires move
> > semantics, that's just the point.
> 
> I though the copy constructor moves the pointer just as well.

unique_ptr has no copy constructor, that's the point. Its move
constructor moves the pointer itself, but it never moves the
pointed-to object. Though I don't see how that's relevant. Again,
the point it that a unique_ptr can't be copied, just moved, by
definition. Bison's parser currently copies its semantic values
which rules out unique_ptr, but according to my patches, it doesn't
need to copy them, moving seems sufficient in all cases.

So the only problems with it are (a) it requires C++11 and
(b) there's no maintainer who could include such a patch, even with
conditionals for backward-compatibility.

> But try shared_ptr then, the difference is just some overhead.

No, as I already explained in my very first mail in this thread.
(Otherwise I'd have done it from the beginning and not started to
patch bison.)

Regards,
Frank