> On 10 Mar 2018, at 01:55, Frank Heckenbach <f.heckenb...@fh-soft.de> 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.



Reply via email to