Ryan Joseph via fpc-pascal schrieb am
Mi., 17. Feb. 2021, 02:15:
>
>
> > On Feb 16, 2021, at 2:43 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > FPC currently does not yet support class types not to mention records
> and objects which is what I had mentioned ear
Ryan Joseph via fpc-pascal schrieb am
Mi., 17. Feb. 2021, 02:21:
>
>
> > On Feb 16, 2021, at 3:35 PM, Benito van der Zander via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > But it is not calling the method, it is calling the wrapper function
>
> what you say wrapper function do
Op 2021-02-17 om 00:02 schreef Benito van der Zander via fpc-pascal:
And there often is a lot of unintentional deep copying. This is also
why a property returning a record is fairly useless except for
extremely small records like TPoint (and even that is not optimal no
But a managed record
Hi,
I have a strange bug, that suddenly Self becomes a random value when
calling an overridden virtual method. It happens when activating a
TCustomSQLQuery.
Below is a gdb stacktrace with fpc 3.3.1, where Self became 0. On other
runs I saw various other values.
Where to start looking?
It happens
> On Feb 17, 2021, at 6:17 AM, Sven Barth wrote:
>
> No. With wrapper function he means the thunks that are responsible for
> adjusting the instance pointer of the interface to the instance pointer of
> the class before jumping to the method of the class.
Oh, so this is some extra code that
> On Feb 17, 2021, at 6:10 AM, Sven Barth wrote:
>
> Simply because no one has come around to implement it yet. The class type
> case is more complicated than the interface case. (Same would be true for
> record and objects)
> So, yes, we'll need to implement this first which would finally br
Hi,
(1) A record is not a pointer. So that would require some implicit
referencing in the property
(2) If it was managed, it would be an allocation, so I don't
understand this.
I am talking about replacing interfaces with an record.
For example this
> On Feb 17, 2021, at 8:27 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> var c: ITest;
> begin
> c := TTest.Create(123);
> c.println;
So this is where you're getting your performance penalties? Correct me if I'm
wrong but two things happen here:
1) Implicit cast to ITest which d
To streamline the discussion, let me recapitulate:
1. multiple inheritance is nice to have, but it has the big issue that the inheritance tree becomes
an inheritance graph and that makes overrules ambiguent.
2. interfaces don't have this issue with multiple inheritance, because they
just decla
On Wed, 17 Feb 2021 15:27:40 +0100
Mattias Gaertner via fpc-pascal wrote:
> Hi,
>
> I have a strange bug, that suddenly Self becomes a random value when
> calling an overridden virtual method. It happens when activating a
> TCustomSQLQuery.
> Below is a gdb stacktrace with fpc 3.3.1, where Self
Hi,
1) Implicit cast to ITest which does a runtime lookup (but there's interface
name so no string comparison like Supports?)
just open the disassembler window in Lazarus and single step through all
the instructions. Then you see everything
create alone calls a bunch of methods:
TInterfac
> On Feb 17, 2021, at 11:11 AM, Benito van der Zander via fpc-pascal
> wrote:
>
> just open the disassembler window in Lazarus and single step through all the
> instructions. Then you see everything
>
> create alone calls a bunch of methods:
>
> TInterfacedObject.NewInstance
> TObject.NewI
On 17.02.21 21:43, Ryan Joseph via fpc-pascal wrote:
So where is your 10% performance hit coming from then?
on init:
InitInterfacePointers or TInterfacedObject.AfterConstruction?
I benchmarked it years ago, I do not remember the details.
But InitInterfacePointers was bad. Just look at it:
> On Feb 17, 2021, at 4:51 PM, Benito van der Zander via fpc-pascal
> wrote:
>
> I benchmarked it years ago, I do not remember the details.
>
> But InitInterfacePointers was bad. Just look at it:
>
That's not great for sure. Fillchar could be a big culprit also actually. I for
one would li
> On Feb 17, 2021, at 9:59 AM, Adriaan van Os via fpc-pascal
> wrote:
>
> 1. multiple inheritance is nice to have, but it has the big issue that the
> inheritance tree becomes an inheritance graph and that makes overrules
> ambiguent.
> 2. interfaces don't have this issue with multiple inhe
15 matches
Mail list logo
