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. Regards, Frank