Re: C++11 move semantics

[Frank Heckenbach]

Hans Åberg 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.

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

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

> > 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!). It's only duplicate accesses within a user
action that prevent unconditional automatic moving.

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

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

Anyway, now that moving works for me, that's a moot point.

Regards,
Frank