bug-bison
[Top][All Lists]
Advanced

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

Re: C++11 move semantics


From: Rici Lake
Subject: Re: C++11 move semantics
Date: Sat, 10 Mar 2018 23:47:56 -0500

On Mar 10, 2018 19:26, "Frank Heckenbach" <address@hidden> wrote:

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?


Here's an example which springs to mind: deeply nested right-associative
operators. As you will see if you follow the link, the issue showed up in a
real application and the problem was not obvious to the person it affected.

https://unix.stackexchange.com/questions/185923/eval-limitation-with-piped-commands/186446



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

Regards,
Frank


reply via email to

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