[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++11 move semantics

From: Hans Åberg
Subject: Re: C++11 move semantics
Date: Mon, 5 Mar 2018 18:53:10 +0100

> On 5 Mar 2018, at 18:15, Frank Heckenbach <address@hidden> wrote:
> Let's see if I can add "$$ = std::move ($1)" as a default action in
> my patches. (Not as a pre-action as in C, that would be wrong with
> move, only as a default action when no user action is supplied.)

That might be OK in this special case.

> So I see no reason why it shouldn't be done by default, especially
> since in C that's not a Bison quirk, but actually a Yacc feature.

I got the impression it might be complicated to implement.

>>> 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.
> The make_FOO functions are generated in the parser (and called from
> the lexer, basically must be called, so one cannot ignore them).
> But there are other places in the parser that also need std::move.
> Actually, you did both of them in your patch in 2015

Yes, I did it if somebody might come by in the future, but I do not have that 
up-to-date myself. 

>>> 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.
> That's unrelated. std::vector does all the std::move's it needs
> internally.

This f you might want to avoid tweaking the M4 file and just change the 

> In user actions, one needs std::move regardless, e.g.
> "$$ = std::move ($1)" (like the default action) or something like
> "$$ = build_something (std::move ($1), std::move ($2))" with some
> user-defined build_something function. That's not poor design; such
> code is expected when using move-only types. But again, the user
> actions are not the issue, bison can't do anything there anyway
> (except for the default action, see above). The required moves
> within the parser are the problem.

It seems to be forced that way, but ideally, the moves should be hidden away in 

>>> 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,
> If one adds copying to unique_ptr, it's not unique anymore. Might as
> well use a raw pointer then.
> GC doesn't call destructors, does it?

One can a could of different things with the Boehm GC, register finalizers, and 
it also a deallocation function. In my code, it proved difficult isolate the GC 
part, so all allocations and deallocation use it, One caveat is that it is slow 
in threading, so if you can avoid it, that is better.

>> and shared_ptr might be an alternative.
> Not for me (in many cases), as I explained.

You will have to explain it again.

>> I was thinking on the deprecated auto_ptr.
> Oh, that! I think it's widely agreed that auto_ptr was a design fail
> (just a hack to try to support moving pre-C++11). Too dangerous to
> accidentally move, and it must not be used with standard containers:
> https://stackoverflow.com/questions/111478/why-is-it-wrong-to-use-stdauto-ptr-with-standard-containers

And it was probably the one that failed with $$ = $1.

>> 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.
> Exactly. That's why I hoped to see a maintainer here.

I can't help you. The CC you removed was to one of them.

>> I do not remember, so you would have to search the list archives. I am just 
>> saying there might a risk there.
>>> Well, search for what?
>> Maybe "variant(s)".
> That's a rather general term. I did some searching, found no such
> thing. Instead found several other requests for moveable types
> (including yours from 2015), so apparently I'm not the only one with
> this problem.

Maybe "C++17" then.

>>> 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.
> Neither me. I guess gcc7 (needed for std::variant) is too early now,
> but std::move only requires C++11 which has been fully supported by
> gcc for a while.

GCC7 seems fine.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]