> On 10 Mar 2018, at 01:55, Frank Heckenbach <[email protected]> wrote: > >> Akim Demaille wrote the C++ parser, and he is not active now. I >> thought the default should have been there, and it is unclear to >> me why it isn't. > > Without move semantics, the cost of a default action (copy) might be > significant.
Indeed. >> Maybe there should be an option for the choice. > > If you like to implement it, go ahead. For me it's too much effort > (implement the option, use it, test it, document it all) for > basically no gain. That would be for the developer of the C++ parser to consider, would there be someone in the future. >>>>>>> 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. >>> 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. > It's only duplicate accesses within a user > action that prevent unconditional automatic moving. Indeed. >>> Well, that's what I've been doing so far, hope to change it. As I >>> said, my parser can suffer a little inefficiency (though with move >>> semantics, it won't even have to), but the rest of my program must >>> not. >> >> Then some reference count might suffice. > > That would mean reimplementing a (simplified) shared_ptr which I'd > preferred to avoid. It is tricky to get right, so something like shared_ptr is best to try first. >>> Nope, reset destroys the object. See the stackoverflow page I linked >>> in my first mail for a discussion. There doesn't seem to be a "nice" >>> way, and that seems to be intentional. >> >> It seems shared_ptr [1] can use a deleter object, which might then >> be set to do nothing. Cf. function 3 in [2] and constructor 5 in >> [3]. > > Something like this was suggested in the stackoverflow page > mentioned, but it seems really kludgy to me. If one would have to sprinkle the code with it, it would not be so useful. > Anyway, now that moving works for me, that's a moot point. Good. Avoid reference counts implemented by hand if you can: too error prone.
