[Top][All Lists]

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

Re: C++11 move semantics

From: Frank Heckenbach
Subject: Re: C++11 move semantics
Date: Sun, 11 Mar 2018 01:26:27 +0100

Hans Åberg wrote:

> >>>>>>> so expensive. Also bison by default reserve()s 200 entries, and I
> >>>> 
> >>> Even if so, it's still a good idea to keep it, so vector basically
> >>> never actually needs to reallocate.
> >> 
> >> It depends on the grammar.
> > 
> > Do you actually have/know a use case with such a deep parse stack?
> It would be hard to know either direction without checking. That
> limit may come from the C parser in the 1980-90s: modern computers
> are so powerful, one could expect anything.

Computers are powerful, sure, but can you think of an actual use
case of so deep nesting?

> >>> Well, std::move works alright. The only rule to remember (which is
> >>> obvious when you consider what moving means) is that you cannot move
> >>> from the same thing twice. To a C++11 programmer, that's natural.
> >>> The question is just if we can make Bison do that automatically, at
> >>> least in most cases.
> >> 
> >> It is interesting to think about: the lifetime objects are known,
> >> but not regulated by the stack.
> > 
> > The stack doesn't have much to do with it. But as far as Bison is
> > concerned, all $n objects are expiring and can be moved from (except
> > in mid-rule actions!).
> Mid-rule actions are implemented using an extra rule.

But they can access the same $n as the final action, so even if they
access them only once, they must not auto-move, unless Bison were to
check the final action, too.

> > It's only duplicate accesses within a user
> > action that prevent unconditional automatic moving.
> Indeed.

Anyway, I think I'm not going to try to implement auto-move now.


reply via email to

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