Re: C++11 move semantics

[Hans Åberg]

> On 5 Mar 2018, at 00:36, Frank Heckenbach <address@hidden> 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.

The default action feature should still be in the C parser, but one can't rely 
on its specifi implementation.

>>> 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++).

So then a bug, perhaps not worth to support, so a change in the manual.

>>>>> 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.

I am only concerned with the parser.

> 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?

If one ends up writing std::move in user code, that is a poor design anyway. 
Simplest for to be use std::deque and avoid copying.

> 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.)

If one adds copying to unique_ptr by the use of a GC, then this what I use, and 
shared_ptr might be an alternative. I was thinking on the deprecated auto_ptr.

>>> 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 have 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.

It is not difficult to hack the M4 file, but if one writes the parser, not 
actively develops for awhile, and Bison changes it, then that may turn out be a 
hurdle say in a few years time.

>> 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.

I do not remember, so you would have to search the list archives. I am just 
saying there might a risk there.

>>>>> 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?

Maybe "variant(s)".

> 
>>>> 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 you might try std::deque or shared_pointer or a GC.

> 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.

GCC7 supports C++17, but I do not know what the developers, would they be 
active, might think.