schrieb am Di., 18. Juni 2019, 03:27:
> >> *this is an example of a traditional record and a traditional object as
> i
> >> think of them...
> > [snip]
> >
> > These would still work as is in FPC.
>
>
> right but are they objects, classes or advanced records?
>
Your example showed a couple of
Le 18/06/2019 à 04:21, J. Gareth Moreton a écrit :
> Hi everyone,
>
> So I sent my last update/fix/patch for the XML core dump feature 3 weeks
> ago, but my main liaison, Pierre, seems to have vanished for the time
> being. Hopefully he's okay, but it means the feature is currently in
>
Hi everyone,
So I sent my last update/fix/patch for the XML core dump feature 3 weeks
ago, but my main liaison, Pierre, seems to have vanished for the time
being. Hopefully he's okay, but it means the feature is currently in
limbo and I could greatly benefit from its use in developing future
On 6/17/19 4:56 PM, Sven Barth via fpc-devel wrote:
Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net:
And yes, both are again different from classes.
yeah, i'll have to see if i can figure out what classes are and if they are
one of the old-school objects or records... yeah, i'm
> 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
> 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
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
Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net:
And yes, both are again different from classes.
yeah, i'll have to see if i can figure out what classes are and if
they are one of the old-school objects or records... yeah, i'm getting
old and rarely dabble in pascal code any more
On 6/17/19 12:49 PM, Sven Barth via fpc-devel wrote:
schrieb am Mo., 17. Juni 2019, 14:15:
On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote:
> schrieb am Mo., 17. Juni 2019, 02:07:
>
> what always confused me these days is that records and objects were
one thing
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
schrieb am Mo., 17. Juni 2019, 14:15:
> On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote:
> > schrieb am Mo., 17.
> > Juni 2019, 02:07:
> >
> > what always confused me these days is that records and objects were
> one thing
> > back in the (TP6) day but today they are something quite
> 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
On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote:
schrieb am Mo., 17.
Juni 2019, 02:07:
what always confused me these days is that records and objects were one
thing
back in the (TP6) day but today they are something quite different... i had
to
be very careful when i wrote my
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
14 matches
Mail list logo
