Re: move constructors

[Rik]

>> If we want to experiment with other solutions, what about introducing
>> move constructors and move assignment operators?  When working with a
>> single thread, that is most often what we want anyway, isn't it?  Can't
>> we define those as well as copy constructors and assignment operators
>> that share resources using reference counting and copy-on-write
>> semantics as before?  Would that help?
>
> Yes, possibly.  In fact, copying/moving is akin to what I described
> above; just a little more sophisticated.  But I think the movement should
> still revolve around that octave_value.  That way, if one is used to
> programming Octave functions in the core, it's essentially the same sort
> of knowledge in the GUI.
>
>
>> I can try to find or define an example class that does what I'm thinking
>> about in the next day or two.
>

This jibes with my sense from the profiling that we are doing a lot of
unnecessary creation/destruction of objects.

*IF* heavyweight constructors are a problem, then calling them less
frequently by using move constructors and move assignment operators would
definitely help.  However, that is still a hypothesis.  Is there a
relatively simple way to test this short of re-writing a bunch of classes?

One option might be to place a counter in the constructor, assignment
operator, and destructor routines for octave_value.

I should also say that I tried implementing a move constructor after
OctConf2018 and I didn't see any improvement.  But, I also could have
screwed it up and I didn't spend a long time on it.

--Rik
I