Ben Grasset schrieb am Mi., 19. Juni 2019, 23:45:
> On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote:
>
>> It’s used for making reference counted types at the user level.
>>
>
> I'm not sure why you'd necessarily need to implement Copy specifically for
> that kind of thing, though. Initialize a
On Wed, Jun 19, 2019 at 6:19 PM Ryan Joseph wrote:
> Because a copy isn’t necessarily an assignment. See the dynamic array
> example again. The only way the record knows it was copied into the array
> is via the copy operator.
>
I guess what I'm trying to get at is:
A) Most of the time, the def
> On Jun 19, 2019, at 5:45 PM, Ben Grasset wrote:
>
> I'm not sure why you'd necessarily need to implement Copy specifically for
> that kind of thing, though. Initialize and Finalize would be much more
> relevant, I'd say.
>
Because a copy isn’t necessarily an assignment. See the dynamic ar
On Wed, Jun 19, 2019 at 5:45 PM Ben Grasset wrote:
> On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote:
>
>> It’s used for making reference counted types at the user level.
>>
>
> I'm not sure why you'd necessarily need to implement Copy specifically for
> that kind of thing, though. Initialize
On Wed, Jun 19, 2019 at 5:02 PM Ryan Joseph wrote:
> It’s used for making reference counted types at the user level.
>
I'm not sure why you'd necessarily need to implement Copy specifically for
that kind of thing, though. Initialize and Finalize would be much more
relevant, I'd say.
> On Jun 19, 2019, at 4:48 PM, Ben Grasset wrote:
>
> What I meant was, does `Copy` actually serve any particular purpose at all
> versus just overloading the assignment operator normally?
>
It’s used for making reference counted types at the user level.
Regards,
Ryan Joseph
__
On Wed, Jun 19, 2019 at 12:01 PM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> It wouldn't matter if the function is called Copy, operator:= or
> "jdjfjsje". Once a copy management operator is defined the record type is
> considered "managed" and thus all assignment operation
Ben Grasset schrieb am Mi., 19. Juni 2019, 16:21:
> On Tue, Jun 18, 2019 at 11:08 AM Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
>
>> Those operators can't be inlined, because they're called from helper
>> code, not from the compiler directly. The LLVM backend won't change
> On Jun 19, 2019, at 10:21 AM, Ben Grasset wrote:
>
> Is there any real purpose to implementing `Copy` versus just implementing
> `operator :=` (or `operator Implicit` when in {$mode Delphi})? Those can be
> inlined, and in practice are used in essentially all the places `Copy` is. By
> whi
On Tue, Jun 18, 2019 at 11:08 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> Those operators can't be inlined, because they're called from helper code,
> not from the compiler directly. The LLVM backend won't change anything here.
>
Is there any real purpose to implementin
Ryan Joseph schrieb am Di., 18. Juni 2019, 16:09:
> Not sure about inline though, I don’t think the compiler inlines these
> operators at all. FPC seems to have lots of non-inlinable code these days
> which is too bad. Maybe the LLVM backend will fix that someday?
>
Those operators can't be inl
> On Jun 18, 2019, at 10:00 AM, Ben Grasset wrote:
>
> Actually, after thinking about it some more, here's what I'd actually write
> (in a perfect world where it was possible.)
>
What I was proposing is that we add another operator called “Move” which will
be called instead of “Copy” if the
On Mon, Jun 17, 2019 at 5:57 PM Ryan Joseph wrote:
> The copy operator is always called on all assignments. Try actually
> running that and you’ll see. :)
>
Actually, after thinking about it some more, here's what I'd actually write
(in a perfect world where it was possible.)
program Test;
{$m
On Mon, Jun 17, 2019 at 5:57 PM Ryan Joseph wrote:
> The copy operator is always called on all assignments. Try actually
> running that and you’ll see. :)
>
Yeah, I noticed that afterwards once I checked. I'm not sure how much sense
that actually makes when the TList is a function *result* as it
> On Jun 17, 2019, at 1:00 PM, Sven Barth via fpc-devel
> wrote:
>
> If we do this at all we should use a separate operator as those two are
> rather different operations and the compiler would already have figured out
> which of the two operations is needed and thus the code inside the oper
> On Jun 17, 2019, at 5:16 PM, Ben Grasset wrote:
>
> I can't actually check the assembly at the moment, but I'm pretty sure if
> your example was written like the following, it would not call `Copy` for the
> `TList.Create(10)` assignment:
>
The copy operator is always called on all assign
On Sun, Jun 16, 2019 at 9:30 AM Ryan Joseph wrote:
> Here’s a little example of the problem. What I propose is that we either
> add a 3rd boolean parameter to the Copy operator or add a new Move operator
> which is preferred over the Copy operator if it exists (this is much more
> work obviously
Ryan Joseph schrieb am So., 16. Juni 2019, 15:29:
> I just came across an efficiency issue when using management operators
> that I’d like to fix before the next release and we have backwards
> compatibility problems.
>
> Basically the problem is that the Copy operator doesn’t know if the source
> On Jun 17, 2019, at 2:19 AM, Jonas Maebe wrote:
>
> And which also causes hard-to-find memory corruption bugs.
How so? I looked into this yesterday and it’s pretty easy to tell if a node is
temporary memory or not, but if there’s a chance it isn’t then calling the copy
operator is still sa
On 2019-06-16 15:29, Ryan Joseph wrote:
Basically the problem is that the Copy operator doesn’t know if the
source value is actually mapped to memory or just a temporary value so
we’re forced to always copy memory (just to be safe) even when a
simple move would be good enough. C++ has a similar i
I just came across an efficiency issue when using management operators that I’d
like to fix before the next release and we have backwards compatibility
problems.
Basically the problem is that the Copy operator doesn’t know if the source
value is actually mapped to memory or just a temporary val
21 matches
Mail list logo
