[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++11 move semantics
From: |
Hans Åberg |
Subject: |
Re: C++11 move semantics |
Date: |
Sat, 10 Mar 2018 10:40:24 +0100 |
> On 10 Mar 2018, at 01:55, Frank Heckenbach <address@hidden> 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.
- Re: C++11 move semantics, (continued)
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/06
- Re: C++11 move semantics, Hans Åberg, 2018/03/07
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/07
- Re: C++11 move semantics, Hans Åberg, 2018/03/08
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/08
- Re: C++11 move semantics, Hans Åberg, 2018/03/09
- Re: C++11 move semantics, Hans Åberg, 2018/03/09
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/09
- Re: C++11 move semantics, Hans Åberg, 2018/03/09
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/09
- Re: C++11 move semantics,
Hans Åberg <=
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/10
- Re: C++11 move semantics, Rici Lake, 2018/03/10
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11
- Re: C++11 move semantics, Hans Åberg, 2018/03/11
- Re: C++11 move semantics, Frank Heckenbach, 2018/03/11