So I've started using the record management operators in earnest and see a real need for another “Move” operator in order to prevent the constant unnecessary copies. If you look at the example in the bug report you’ll see where adding a Move operator will save you 2 copies and that it works as a companion to the Copy operator, meaning if you don’t declare Move then Copy will be called by default.

I don’t think I captured all instances where a copy could be detected (I could use some help there) but at least it works in the most common situations. I think it’s a no-brainer to include this but I wanted to post the patch so you could see how it worked and if it’s worth it in terms of added complexity.

https://bugs.freepascal.org/view.php?id=35825

Regards,
Ryan Joseph

Ryan Joseph wrote

So I've started using the record management operators in earnest and see a real need for another “Move” operator in order to prevent the constant unnecessary copies. If you look at the example in the bug report you’ll see where adding a Move operator will save you 2 copies and that it works as a companion to the Copy operator, meaning if you don’t declare Move then Copy will be called by default.

In which scenarios do you need such a custom "move" operator, rather than simply allowing the compiler to just copy the data from one place to the other without calling a destructor on the old instance?

I can only imagine this would be a problem if your managed record constructor/destructor automatically register/unregister pointers to these managed record instances in another datastructure, but is that valid in any case?

Jonas

Not sure off the top of my head what would happen if the user simply wasn’t informed about the operation but it makes me nervous. :) It may be the case though that inside the move operator the most common thing is just to call System.Move anyways. Also if the operator isn’t there then there’s no way to know without a modeswitch or some other syntax that the user wants to calls system.move instead of the Copy operator.

Hmm, not sure what you mean. If look at the bug report (https://bugs.freepascal.org/view.php?id=35825) I did find some bugs relating to nested records and fixed them. You can apply the patch or test with https://github.com/genericptr/freepascal/tree/moveop

Regards,
Ryan Joseph

The question then still remains: why would a user want to call a copy operator when the data is just moved from a temp to another place? Having an explicit copy operator when there is no use case for it only requires programmers to write extra code that can contain bugs.

Jonas

Your point is well taken but I really don’t have any better answer than it doesn’t feel balanced with the copy operator in that same level of control to the user. Using the management operators it feels like your opting into having the compiler tell you when it’s performing certain operations on the record so it feels wrong that the move operation is happening without telling you. Just my feelings though. :)

Do you have another proposal then? If there’s no move operator then there’s no way to signal that a move is going to override the usual copy operator call which happens every time. I guess the only other viable option would be a modeswitch or some other compiler directive to toggle on/off.

Regards,
Ryan Joseph

You are assuming here that there is a problem. Has it occurred to you that maybe there is no problem and that a solution is simply not needed?

Sounds to me like you're simply needlessly complicating simple things: moving data from one location in memory to another.

Michael.

On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt wrote: You are assuming here that there is a problem. Has it occurred to you that maybe there is no problem and that a solution is simply not needed?

How is this not a problem? Sorry I don’t follow you.

Regards,
Ryan Joseph

You propose a new operator: a move operator.

Maybe there is no need for a move operator ? I have not seen any argument that makes the need for this operator crystal clear.

When I read your proposal, my first thought was:
"solution looking for a problem."

Michael.

Look at my bug report for some examples. The problem is if you implement the copy operator it MUST be called for all assignments and this results in double, triple etc… copies of the underlying data even though a simple move would be sufficient. It’s an efficiency thing and it should be improved.

Regards,
Ryan Joseph