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
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
> 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
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
Виктор Матузенко schrieb am Mi., 19. Juni 2019, 16:25:
>
>
> ср, 19 июн. 2019 г. в 17:10, Marco van de Voort >:
>
>>
>> No. Such guarantees/constraints on a long term basis would paralyse the
>> project too much. We try to avoid breaking backwards compatibility as
>> much as possible, but we
Marco van de Voort schrieb am Mi., 19. Juni
2019, 16:09:
> > The answer I see: none because any identifier may become "builtin",
>
> > start to hardly conflict with any declarations with the same name and
> > become PITA for code maintainer.
> >
> No, since the default is that the local
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
> 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
>
ср, 19 июн. 2019 г. в 17:10, Marco van de Voort :
>
> No. Such guarantees/constraints on a long term basis would paralyse the
> project too much. We try to avoid breaking backwards compatibility as
> much as possible, but we can't always guarantee it absolutely.
>
>
Ok, just for clarification: is
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
Op 2019-06-19 om 15:55 schreef Виктор Матузенко:
First, where would be the breakage? Now it works with and without
overload?
If I write a unit that overloads the Pos function and code that uses
the unit
and calls standard version of Pos without namespace prefix, than this code
will be
ср, 19 июн. 2019 г. в 15:34, Marco van de Voort :
>
> If the documentation lists the function as being in "system.fpd" that is
> probably it. You can look at that file (rtl/inc in the sources) to get
> an idea.
>
Ok, thanks.
> First, where would be the breakage? Now it works with and without
Op 2019-06-19 om 14:30 schreef Виктор Матузенко:
Thanks for the answer!
ср, 19 июн. 2019 г. в 15:07, Marco van de Voort
mailto:f...@pascalprogramming.org>>:
- Copy and length are builtins, pos is a function.
builtin+function is
not "true" overloading since both are not the same
Thanks for the answer!
ср, 19 июн. 2019 г. в 15:07, Marco van de Voort :
>
> - Copy and length are builtins, pos is a function. builtin+function is
> not "true" overloading since both are not the same kind.
>
>
Is the term "builtin" documented somewhere? Where can I find list of
all builtin
Op 2019-06-19 om 13:46 schreef Виктор Матузенко:
Pos behaves differently than Length and Copy.
Seems inconsistent -- should it be considered as a bug?
Afaik:
- Copy and length are builtins, pos is a function. builtin+function is
not "true" overloading since both are not the same kind.
-
Hi!
I am writing my own string type and I want to overload standard string
functions.
I don't want to hide them, just overload.
Consider the following example (I use 3.0.4 [2017/10/06] for i386):
===
{$MODE FPC}
type
TMyString = record
end;
function
19 matches
Mail list logo
